As a Web Developer, I should Add a Checkbox

I am dedicated to staying sane.  Sanity is not an option.

But providing options may save your sanity, if you are a web developer.  Clients will rarely ask for the ability to turn something on and off.  Instead, they will describe the feature’s settings and appearance, but inevitably they will forget to tell you to create a KILL SWITCH.

If the default is for this feature to be on, set the checkbox to being checked by default.  Then you’ve got a kill switch if you ever need to turn it off.

When should you add a checkbox?

Here are some hints that you should have a checkbox for enabling or disabling the new feature you’re building:

  • Feature depends on a third-party service.  If you have no control over the service, and if the rest of the site does not depend on that service, add a checkbox.  This allows you to quickly disable the integration if problems arise or billing agreements change.
  • Other similar features have a way to be enabled/disabled.  This makes it likely that the client has the same expectations this time.  If you’re new to the project, ask around and check out existing code.
  • Feature may interfere with other site features.  Think about this from both design and functionality standpoints.
  • Feature needs to be deployed at an exact time.  Your time is valuable.  You should take control of your life.  Add a checkbox, deploy it ahead of time, tell client they can turn it on whenever they want.  Win-win.  This assumes that it’s been thoroughly tested on a staging server and you’re not concerned about any immediate issues.
  • How static is the website?  The more complex and ever-changing it is, the more likely you’ll wish you had that checkbox.

 

Hiding Posts in WordPress with a Custom Post Status

Are you looking for a way to hide WordPress posts from both the frontend and the backend?

By default, WordPress displays all post statuses on the backend post list admin screen.  To specifically tell it to exclude a post status, you’ll want to register the post status with the following arguments:

function themeprefix_register_inactive_post_status() {
   register_post_status(
      'prefix-inactive',
      [
         'label' => 'Inactive',
         'public' => false,
         'internal' => true,
         'protected' => true,
         'private' => false,
         'exclude_from_search' => true,
         'publicly_queryable' => false,
         'show_in_admin_all_list' => false,
      ]
   );
}

add_action( 'init', 'themeprefix_register_inactive_post_status' );

I recommend prefixing the post status to avoid potential conflicts — just incase WordPress or a plugin decides to register an inactive post status themselves.

One unintuitive thing is that “private” actually needs to be set to “false” as shown above.

So why would you do this?

In most cases, I’d recommend differentiating types of posts by using a different post type instead of a different post status.

However, in my case, I wanted a way to “soft delete” posts without moving them to the trash.  See, the trash auto-empties after 30 days, and if you move all of the posts to the trash at once, then in 30 days, all of them will be deleted at once, and this could cause some performance issues if you’re dealing with thousands of posts.

So instead I made an inactive post status, and wrote a WP CLI script to set this post status on the content I planned on deleting.  This way I could restore the content if needed, so it’s truly a “soft delete”.  Then, when I want to permanently delete it, I’ll write another custom WP CLI script that permanently deletes them.  This script will sleep at set intervals and also will take other measures to make sure that we don’t cause performance issues!

 

Setting up PhpStorm, Xdebug to work with WordPress PHPUnit Testing

I’m a huge fan of using Xdebug and recently I ran into some issues with writing PHPUnit tests for my WordPress theme.  It took me longer to debug than usual because I couldn’t get PhpStorm to stop at my debug breakpoint.  Actually, I couldn’t get Xdebug to work at all — if I had Xdebug enabled, PHPUnit wouldn’t even run — it would just hang.

I tracked the issue down to this line in tests/bootstrap.php

system( WP_PHP_BINARY . ' ' . escapeshellarg( dirname( __FILE__ ) . '/install.php' ) . ' ' . escapeshellarg( $config_file_path ) . ' ' . $multisite );

A Google search brought me to this closed WP Core trac ticket.

That ticket has a helpful suggestion, which I hope to immortalize here, as it is the solution to this problem.

Max. Simultaneous Connections Setting

The solution is to change the Max. simultaneous connections setting, which can be found in Default preferences -> Languages and Frameworks -> PHP -> Debug.

Increase the phpStorm max connections setting to get xdebug to work.

“Configure Php Include Paths”

The default setting is 1, change it to 3 or more!

Tada!!

If that doesn’t solve your problem instantly, then I shall ask, did you Configure php include paths so that the phpunit files are included?  Also, depending on your development environment, you may need to set up path mappings so that PhpStorm knows how the server files are mapped to your local ones.

Happy testing!