Tag: WordPress

Copying theme mods to child theme using wp-cli

“Child themes” in WordPress allow for specific modifications of the look and functionality of those inherited from their “parent” theme. Unfortunately, when you switch to the child theme, the customizations configured on the parent theme are lost, because they’re saved with the active theme slug. So, here’s a quick and simple way to “inherit” those… Continue reading Copying theme mods to child theme using wp-cli

Registering custom URLs with custom templates in WordPress (without using page templates)

It’s fairly common to find yourself on a situation where you want to use a specific URL to show a custom content (perhaps something an archive page with two different custom post types), and think: “well, that’s easy. I’ll just create a page to register the URL and a custom page template where I’ll query… Continue reading Registering custom URLs with custom templates in WordPress (without using page templates)

Mitigating CVE-2018-6389 WordPress DoS attack with lighttpd

Early in 2018, Barak Tawily published a possible DoS attack for WordPress, that basically works by requesting all possible scripts on the /wp-admin/load-scripts.php, a script that fetches and concatenates javascript files — there’s also a load-styles.php file that does the same for styles. His vulnerability report was rejected by the WordPress team, on the account… Continue reading Mitigating CVE-2018-6389 WordPress DoS attack with lighttpd

When using a navigation menu on WordPress, you’ve probably seen the various HTML classes that are added on active elements, such as current-menu-item, current-menu-parent, current-menu-ancestor…

While that kind of classes are fine if you must fully reflect the navigation hierarchy on the menu element, there are some times that you just need a more simple approach, such as just knowing when a certain menu element must look like the active item —for instance, when using Bootstrap.

For these kind of situations, you can use a simple filter to add such a class; something like:

<?php

add_filter('nav_menu_css_class', function ($classes, $item, $args, $depth) {
    // filter by some condition... for instance, only on the "main" menu
    if ( $args->theme_location !== 'main' ) {
        return $classes;
    }
    // all the different "active" classes added by WordPress
    $active = [
        'current-menu-item', 
        'current-menu-parent', 
        'current-menu-ancestor', 
        'current_page_item'
    ];
    // if anything matches, add the "active" class
    if ( array_intersect( $active, $classes ) ) {
        $classes[] = 'active';
    }
    return $classes;
}, 10, 4);

When you’re developing a WordPress plugin, there are certain patterns and practices that are extremely useful to know and apply in order to get a better fit with the platform as a whole.

One of these things it’s what’s the better way to initialize a class on a plugin, which this answer on the WordPress StackExchange covers in great detail, while also explaining other interesting topics and recommendations such as using an autoloader and global access, registry and service locator patterns.

While you’re at it, you might also want to check these posts from Tom McFarlin:

 

Basic Authentication it’s often used as a simple security measure or as a temporary authentication method while developing with certain APIs.

While the WordPress HTTP API doesn’t have explicit support for basic authentication, it’s still possible to use it as a header:

$request = wp_remote_post(
  $remote_api_endpoint,
  array(
    'body'    => array( 'foo' => 'bar' ),
    'headers' => array(
      'Authorization' => 'Basic '. base64_encode( $username .':'. $password )
    )
  )
);

Remember that if you’re sending an unencrypted request, all the headers will be sent in plain text, so you should only use it over HTTPS.