if all else fails…code something

Kokkie's coding journal

  • WP-CLI

    WP-CLI is the command-line tool for interacting and managing a WordPress site. I’ve used the limited version we have for supporting some sites on WordPress.com before, but my self-hosted sites are hosted at Pressable which (at least, last I checked), doesn’t support WP-CLI, so I wouldn’t say I’m comfortable with it.

    I’m starting on a new project (a single-page application built on WordPress), and my coding mentor has instructed me to use wp scaffold plugin for it.

    I mostly use Local by Flywheel for my local sites (though wp-env via Docker is also very useful). Local sites come with WP-CLI already installed, but you need to open a site Shell from within Local to use it.

    In my search for that information, I also came across several articles explaining how to get around that requirement, to just run WP-CLI directly from Terminal, so I thought I’d give that a try.

    You need to add two files to the Local site’s root folder to tell WordPress where to find WP-CLI. For a future reference to myself:

    wp-cli.local.yml must contain this content:

    path: app/public
require:
  - wp-cli.local.php

    And wp-cli.local.php must look like this, with the localhost value being the “Socket” value under the Database tab for the site in Local:

    <?php
define('DB_HOST', 'localhost:/Users/sal/Library/Application Support/Local/run/lBW9-Gu_J/mysql/mysqld.sock');

// Only display fatal run-time errors.
// See http://php.net/manual/en/errorfunc.constants.php.
error_reporting(E_ERROR);

// Disable WordPress debug mode.
// See https://codex.wordpress.org/WP_DEBUG.
define('WP_DEBUG', false);

    Props to Sal Ferrarello for the detailed explanation.

    Of course, after doing this WP-CLI didn’t work, cause apparently this doesn’t use the WP-CLI version already installed on the Local site, but instead looks for it on my computer itself. So as the final step I installed WP-CLI using Homebrew.

    And now I can manage my local site using WP-CLI. Yay!

  • Let’s Localize

    I spent today figuring out how to internationalize my plugin.

    There’s a LOT of different translation functions, and it’s going to take a while to learn when it’s best to use which one, but for now all the text my plugin is adding is translation-ready, so yay!

    I mostly followed the steps in Professional WordPress Plugin Development, though it missed a crucial step in how to create the actual .pot file using Poedit: It explained that .po and .mo files must have the locale-id included in the filename, but then proceeded with instructions to create a .pot file which doesn’t contain the locale-id (and which you can’t actually save using Poedit.

    After struggling for probably an hour, checking and re-checking my Text Domain and Domain Path, I finally turned to the WordPress StackExchange. It didn’t have my answer exactly, but it pointed me to the plugin handbook on WordPress.org, which explained how to get the .pot file, along with locale-specific .po and .mo files. And my translations worked!

    Another challenge was figuring out how to include a link in a string. Just including the URL (including HTML) in the string didn’t work – Poedit for some reason turned quotes into smart quotes in the translation, which broke the link. Next I broke the string up into different parts, which worked, but I realised it will be a problem in languages that change the word order.

    I moved the URL (including the opening <a> tag) to a variable, so I could use a placeholder, and just added the closing </a> tag via concatenation…before I realised that’s really dumb – separating the closing tag from the opening one could completely change what’s actually linked should the order of words in the string change.

    I was stumped on how to solve it, so took to StackExchange again. I’m a bit confused at this part of the solution: '<a href="%s">%s</a>'. Specifically, why do we repeat the %s placeholder, rather than using numbered placeholders here? I’ll need to ask someone about that.

    Some TILs:

    • Text Domain must match the plugin slug/folder name
    • If internationalizing a string you’re echoing, use _e rather than __
    • If using return in a function, printf doesn’t work – use sprintf
    • It’s possible to nest translation functions inside one another
    ,
    , , ,

  • Getting familiar with child themes

    I’ve started on a project to create a custom WooCommerce site, and the first step is to create a Storefront child theme and make some customizations.

    The initial steps from the WordPress.org developer documentation is pretty straightforward – create a folder for the child theme with its own style.css and functions.php files. I made a CSS modification to the header background colour to test, and it seems Storefront automatically loads the child theme’s style.css file, as the WordPress.org documentation said it might. But I’m not sure where or how Storefront does this.

    I added a couple more style changes, but then wanted to remove the footer credit. Doing it via CSS is simple enough, but typically not recommended. One could also use a plugin for this, but the whole point of this project is to learn how WordPress works on the code level.

    Logic says the footer comes from footer.php, so I checked that file in the parent theme, but the footer credit text isn’t there. Instead, that file only contains this bit of PHP:

    <?php
/**
* Functions hooked in to storefront_footer action
*
* @hooked storefront_footer_widgets - 10
* @hooked storefront_credit         - 20
*/
do_action( 'storefront_footer' );
?>

    Searching the theme for storefront_credit lead me to the file, storefront-template-functions.php, which contains a function with that name that adds the footer credit, a link to the privacy policy page, and a copyright notice. I decided I only want to keep the copyright notice, so it was clear I need to remove the two if-statements that add the first two items.

    According to the child theme documentation, “any file you add to your child theme will overwrite the same file in the parent theme.” So I created a copy of storefront-template-functions.php in my child theme, removing the code. It didn’t work.

    After trying a few different things that didn’t work, I realised I probably need to add the function to my child theme’s functions.php instead. I added the following:

    if ( ! function_exists( 'storefront_credit' ) ) {
	/**
	 * Display the theme credit
	 *
	 * @since  1.0.0
	 * @return void
	 */
	function storefront_credit() {
		$links_output = '';

		$links_output = apply_filters( 'storefront_credit_links_output', $links_output );
		?>
		<div class="site-info">
			<?php echo esc_html( apply_filters( 'storefront_copyright_text', $content = '&copy; ' . get_bloginfo( 'name' ) . ' ' . gmdate( 'Y' ) ) ); ?>

		</div><!-- .site-info -->
		<?php
	}
}

    And would you believe it, that worked – gone is the footer credit from my site.

    So I’m guessing when it comes to functions specifically, they should be replaced in functions.php, while for non-function content of theme files, a copy of the file in the child theme is the way to go.

    One thing I’m not sure of: Do I still need the if-statement wrapping the function in my child theme? Based on the child theme documentation, that’s there to make the function pluggable, that is, replaceable by a child theme. And it appears to work with or without that statement, so I don’t think it’s necessary. But what is the standard practice here?

    ,
    , , ,
Design a site like this with WordPress.com
Get started