Category: WordPress

  • No comments after business hours

    No comments after business hours

    TBH, managing your blog’s comments can sometimes feel like a second job. You want engagement, you love the discussion, but it can also be kind of a drag. For me, especially as I’ve started regularly posting here again, I wanted to maintain some of my off-hours peace without keeping comments off entirely.

    My solution? Setting up business hours — an idea I feel like I stole from Jenn Schiffer, who was maybe doing business hours for some other project of hers — for when folks can leave new comments. Kind of like a brick-and-mortar shop. And the best part? I did it with Nick Diego’s fantastic Block Visibility plugin for WordPress.

    The idea was a simple one: I wanted the comment submission form on my posts to only be visible and submittable between 9:00 AM and 5:00 PM, Monday – Friday, Pacific Time.

    Any comments left during those hours, or any that were already on my site before I flipped this switch, still get displayed perfectly fine. It’s not about silencing discussion — but rather managing when the door is open for people to stop by and talk.

    As I mentioned, the Block Visibility plugin is a lifesaver for this kind of control over all sorts of site components. It lets you set conditions for when any block (or group of blocks) should appear. In this scenario, I’m using the Twenty Twenty-Five theme — though this should work with any block theme — and the process is surprisingly straightforward.

    Once you’ve installed and activated Block Visibility, here’s what you need to do:

    1. Edit your Single Post template: Head into your Site Editor (Appearance → Editor) and navigate to your site’s Single Post template.
    2. Select the appropriate block: Find the block responsible for rendering the actual form where visitors type their comments. In my case, and in many themes, this is the Post Comments Form block.
    3. Open Block Visibility settings: With the block selected, look for the Block Visibility settings in the block inspector panel on the right. You might need to click the lil three-dot menu on the block’s toolbar to find Visibility — or it might be a dedicated panel.
    4. Set the Schedule: This is where the magic happens!
      • Click to add a Date & Time visibility control.
      • You’ll want to set it to Show the block if the schedule applies.
      • For the days, uncheck Saturday and Sunday, leaving Monday, Tuesday, Wednesday, Thursday, and Friday selected.
      • Under During this time interval, set FROM to 09:00 AM and “TO” to 05:00 PM.

    And that’s pretty much it. Now, your site’s comment form will only appear during your designated business hours.

    I also like to add a little notice above the comment area (using a Paragraph block) to let folks know about the commenting hours.

    Something like “The ability to comment on posts is available only during business hours (Monday – Friday, 9am – 5pm UTC).” works just fine.

    It all sounds pretty simple, right? Well, there’s a little wrinkle that I ran into. You might too, depending on your hosting setup.

    Caching is great for site speed, but it can also mean that your comment form might stay open after 5pm or closed after 9am because the cached version of a page is still being served.

    My site is hosted with SpinupWP, which has its own caching layer, on top of object caching. To make sure the changes kick in as promptly as possible, I had to get a touch more technical and set up some server side cron jobs.

    For those comfortable with the command line, or for those whose hosts provide cron access, here’s the fix. I set up two cron jobs: one to run just after comments close, and one to run just after they open.

    Here’s some genericized versions of what I use in cron. You’ll need to adjust the paths and specific caching commands for your own hosting environment:

    # Clear WordPress object cache and [$host] site cache at 9:01 AM, Monday-Friday
    1 9 * * 1-5  cd /path/to/your/wordpress/install && wp cache flush && wp cache purge-site
    
    # Clear WordPress object cache and [$host] site cache at 5:01 PM, Monday-Friday
    1 17 * * 1-5 cd /path/to/your/wordpress/install && wp cache flush && wp cache purge-site
    

    What’s happening here?

    • 1 9 * * 1-5: This is the cron schedule. It means run this command at minute 1, past hour 9 (9:01 AM), Monday through Friday.
    • The second schedule is the same but timed for 17:01 (5:01 PM), also Monday through Friday.
    • cd /path/to/your/wordpress/install: This makes sure the command gets run where your WordPress files live.
    • wp cache flush: This is a WP-CLI command to flush the WordPress object cache.
    • wp cache purge-site: This is a placeholder for your hosting provider’s specific WP-CLI command to purge their site-level cache.

    By running these a minute after the scheduled change to block visibility, we ensure that any cached pages are cleared, and the correct state of the comment form (visible or hidden) is served to visitors.

    It might seem like there’s a few hoops to jump through, especially if caching is a factor for you, but I swear that it’s totally worth it. My site (and its visitors) now respect my office hours, past comments still get displayed, and I’m not tied down by stupid moderation duties.

  • Return of the Slack

    While I find the official WordPress Slack team incredibly useful, the sheer scope of it — over 10,000 users & 66 channels — makes the copy of Slack on my desktop ridiculously sluggish. It’s actually pretty crazy how much lower the RAM usage on my machine is when I remove the WordPress team from the app.

    At this point I feel like my options are:

    1. Stop hanging out in WordPress Slack. 😞
    2. Requisition a new work machine with more RAM. For Slack. 😕
    3. Shut up and continue to deal with it. 💩

    I’ve gone with a modified version of option #3 thanks to Nativefier. It quickly wraps any site in an Electron shell and creates an executable for your operating system. So now I’ve got an app just for WordPress Slack. My (7) other teams can stay snappy and I can restart the Electron app as needed when RAM gets tight.

    And if you’re using a Mac, you can have it too… Just click the image below to grab a (totally unsupported) copy.

    wp-core-slack

    Pardon the hastily thrown together icon. It’s this Dribbble shot plus a plain ol’ WordPress logo. To be honest, I wasn’t looking to blow a whole lot of time on this. And I didn’t. So that’s cool.

    Hopefully at least one other person finds this useful!

  • Playing with Laravel Valet

    I finally had the chance to do a little WordPress work in Laravel’s lightweight development environment Valet last week. My hot take?

    It's the best. I love it.

    If you’re interested in setting it up on your Mac, there’s a solid tutorial that outlines how to get started by Tom McFarlin over at Tuts+. And if you’d like to go down the rabbit hole even further, Aaron Rutley has written a script that helps you create and delete sites under Valet in seconds.

    I’m going to spend a little more time with this over the coming weeks. Maybe I’ll put something interesting together if I can find the time… No promises though.

  • Simple Cache

    GitHub – tlovett1/simple-cache: A simple caching plugin for WordPress.
    A simple caching plugin for WordPress. Contribute to tlovett1/simple-cache development by creating an account on GitHub.
    github.com

    Taylor has been on fucking fire lately with plugin releases. Simple Cache does one thing — caching, natch — and it does it very well:

    Simple Cache was constructed after getting frustrated with the major caching plugins available and building sites with developer-only complex caching solutions that get millions of page views per day.

    If you need your site to run fast, don’t have time to mess with complicated settings, and have been frustrated by other caching plugins, give Simple Cache a try.

    Sounds nice. Wish I had an unmanaged site to use this on.

  • Reasons for Custom Tables and an API

    Custom Database API – Reasons for Custom Tables and an API – Pippins Plugins
    pippinsplugins.com

    When it comes to storing large amounts of data that does not very closely mimic existing WordPress database schemas, you should absolutely use custom tables. Choosing not to use a custom table will likely cause more harm than good. While it’s possible to store almost anything you want as a custom post type in the wp_posts table, that does not mean you should or that it is even a remotely good idea.

    You have no idea how happy I am that someone is finally saying this. I’m even happier that the someone saying it is Pippin.

    Really looking forward to the rest of the articles in this series!

  • Gotta Podcatch ‘Em All

    A couple great WordPress podcasts — WP Dev Table and WPwatercooler — have been nice enough to have me on as a guest recently. Instead of having you dig around each site to find the episodes, I’ll just go ahead and leave them here…

    Episode 11 – A Day In The Life of a Developer Advocate at WP Engine with Jason Cosper
    EP 148 – Coding and the design process – Aug 10 2015

    As you can see, I’m a pretty insightful guy. Humble too.

    Want to have me on your podcast? Hit me up on Twitter!

  • Shortcake Bakery

    GitHub – wp-shortcake/shortcake-bakery: A fine selection of shortcodes for WordPress
    A fine selection of shortcodes for WordPress. Contribute to wp-shortcake/shortcake-bakery development by creating an account on GitHub.
    github.com

    Shortcake + Shortcake Bakery = Easy PDF, JavaScript, iFrame, Facebook post, Scribd & Genius embeds from the team at Fusion.

    There’s also a really nice image comparison tool. If you’re into that sort of thing. Which I am.

  • WPScan Licensing

    WPScan Licensing
    When you first release software online you don’t put too much thought into the software license (I didn’t at least). You have no idea if the project will tak…
    web.archive.org

    It looks like the WordPress security tool WPScan is looking to move away from the GNU GPL license for their software. That’s rather unfortunate, but after reading about companies trying to repackage and sell WPScan as their own work, I totally get where they’re coming from.

    Chasing these companies takes time, sometimes a whole day of emails back and forth arguing the intricacies of the GNU GPL while they try and weasel their way out of complying to our license. This takes a lot of my time away from the important stuff, working on WPScan and the WPScan Vulnerability Database. Because of this I decided to add a clause to the license. If you want to sell WPScan you can pay for a commercial license, otherwise you can use it under the GNU GPL.

    After a few months with this license it was pointed out to me that the GNU GPL does not allow these kind of clauses. What some individuals and companies decided was a ‘loophole’.

    Their new (proposed) license has been posted as a Gist — which I’ve embedded below — and the developers are welcoming feedback.

    If you’re schooled in Public/Open Source software licenses and are interested in the future of WordPress security tools, go leave a comment!

  • Making Your Own High Performance WordPress Server

    Making your own High Performance WordPress Server | Zach Adams | Boise Web Design and Development – Making your own WPEngine-Like High Performance WordPress Server
    Web Developer and Programmer
    zach-adams.com

    Clever forks of WP Engine’s Mercury Vagrant for the “roll your own server” types courtesy of Zach Adams.

    I say “forks” because he’s actually crafted two different Ansible playbooks. One deploys  WordPress, HHVM, Percona, PHP-FPM & nginx to a server of your choosing while the other adds Varnish, Memcached & APC to the mix.

    I have a vested interest in folks signing up for service at WP Engine — seeing as how I work there and all that — but this is still pretty fantastic.