Category: Geekery

  • 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.

  • Pocket lint

    Pocket lint

    Well, damn… Pocket is heading off into the sunset. For those of us who saved articles there, this stings. The internet’s a goddamn firehose, and Pocket was a decent enough bucket.

    So, what now? Panic? Freak out? Declare reading list bankruptcy? Nah. There are still ways to hoard your digital treasures.

    When a beloved service shutters, some folks immediately go towards self-hosting. Building your own keep! Be the master of your data!

    I get the appeal. But let’s be real, server maintenance can be a pain in the ass that very few people actually want.

    Make it someone else’s problem

    If you prefer tech that just works without constant futzing, there are solid, affordable open source packages that offer hosted solutions. My top picks are Readeck and Wallabag. You can get ’em hosted for less than a couple of bucks a month. Seriously.

    • Readeck: A clean, straightforward reader. It archives webpages for offline reading with a no-nonsense interface. Honestly, it gets the job done.
    • Wallabag: This open-source option is way more feature rich. It grabs content, has mobile apps, and even supports annotations if you’re of the note taking persuasion.

    “But who,” you might ask, “hosts these for pocket change?”

    Enter PikaPods.

    PikaPods is a great low frills resource for managed web app hosting. While their catalog is limited to a few handfuls worth of apps, they handle upgrades, security, and any of those annoying 3 AM reboots.

    You just send them a few bucks a month — under $2 for both Readeck and Wallabag — and they keep your app running. It costs as much as gas station coffee and solves your problem. No brainer, right?

    Make it your own problem

    Alright, you’re determined. I get it. You want the full neckbeard experience. I can respect that. All you need to do in this case is grab a Raspberry Pi (a 4 or 5 is good, more RAM is always better) and install YunoHost.

    YunoHost is a server control panel aiming to make self-hosting accessible — even if you’re not a command-line wizard — via a surprisingly friendly dashboard for one-click app management.

    Their app catalog is pretty well-stocked for article hoarders:

    • Wallabag (See above)
    • Readeck (Ditto)
    • Linkwarden: More of a bookmark manager with archiving, but still super useful.
    • ArchiveBox: For serious digital packrats, this creates full local website archives.

    The main catch with YunoHost on a RasPi? You’ve gotta update your apps and the YunoHost software itself occasionally. It’s not really a huge burden — YunoHost’s dashboard helps — but slack off, and you’re asking for security problems or broken shit.

    The TL;DR

    Losing Pocket is a bummer, sure. But it’s also a chance to find a new thing that’ll stick around for a good long while thanks to beautiful nerds who also like to hoard articles for years and years and maintain free software.

    For a low-stress, dead-simple solution, PikaPods managing Readeck or Wallabag for a tiny fee is fantastic. Minimal fuss.

    If you’re feeling adventurous, have a Raspberry Pi kicking around your junk bin — or need an excuse to buy yet another one — and don’t mind a bit of tinkering, YunoHost offers a powerful, surprisingly user-friendly way to wrangle things.

    Anyway, your digital hoarding habit isn’t dead — it’s just evolving! Pick your poison, save those tabs, and keep telling yourself that you’ll read them later.

  • A Wappalyzer of my very own

    So, y’all know how it is sometimes… You go digging through GitHub repos looking to see if anyone’s already made a tool to do a specific thing that you need to get done. Something simple and fast that doesn’t do a bunch of extra stuff. Lately, I’ve been wanting a quick way to peek at what sites have been built with without having to tab away from the terminal or poll some third party API. Just a straightforward command-line thing.

    While poking around, I stumbled across a project that wrapped a Go implementation of Wappalyzer in a CLI. Sounds perfect, right? Go is fast, the command line is fast, and Wappalyzer does the thing that I need.

    The old version worked alright — no complaints, really — but nothing on the project had been touched in three years. The Go version was old, libraries were way out of date, and honestly, relying on something that stale just feels… irresponsible?

    Besides, the JSON output that the old version of the Wappalyzer CLI spit out didn’t include the domain name. Which made it slightly less useful when performing runs on a list of domains, which I’m possibly looking at doing.

    Before I start talking about my fixes tho, here’s a quick note on how this tool works. When run, wappalyzer-cli fetches the target site via HTTP, pulling HTML, headers, JavaScript, etc. Then it uses a local database of known libraries, frameworks, and server technologies. No external API calls need to be made for analysis. All of this happens locally.

    I consider this a massive win for privacy! The URLs you scan and site contents all stay on your machine. This means that you’re not feeding some rent seeking business that’ll most likely turn around and eventually funnel this data into some bullshit AI tool. On top of that, you can use this as much as you want without worrying about hitting any API rate limits.

    Anyway, I decided to give this neglected tool a friendly bit of polish. I started by switching things to a more recent version of Go. Then I bumped all of the dependencies. Once that was done, I ensured that everything still ran. Finally, I hacked the domain name into to the JSON output. Now I’ll be able to tell which site each set of results belongs to in batch runs.

    It’s still the same fast tool that it was before. It’s just a bit better now. If you want a quick, reliable site intelligence tool, go check out my updated version over on GitHub.

    Feel free to kick the tires, open an issue, or send a pull request if you’re really feeling sassy. I’m still learning Go, so it might take a minute for me to figure out how to fix whatever bugs folks might surface, but I’m still happy to give it the old college try.

  • Automaddic

    Automad / A Flat-File CMS and Template Engine
    Automad is a fast and lightweight flat-file content management system and template engine for creatives that can be used in a monolithic or headless mode.
    automad.org

    After spending close to twenty years clicking around the WordPress dashboard, I’m finding Automad’s whole “minimalist CMS” vibe deeply refreshing.

    I played with a demo of version 2, goofed around a bit with the extensions on offer, and not once did I have to dismiss a dashboard notification or suffer through a premium upsell offer. Truly glorious.

    The fact that it’s written in PHP — something that I have plenty of experience with — is also pretty damn nice.

    I’m definitely going to have to spend some more time messing around with this.

  • A Quick Take On Guetzli

    I ran a few (incredibly unscientific) tests on Google’s new Guetzli JPEG encoder last night at 100%, 90%, and 84% compression. Why 84%? Well, that’s the lowest the Guetzli binary will let you go without editing the source and recompiling.

    Each run (compressing a single image) took about 20 minutes on a medium sized cloud instance with 8GB of RAM. During these runs, the server routinely went into swap. If you’re interested in seeing how things panned out, here’s the output: https://img.boogah.org/g/

    Included in the link above are 2 versions (lossless, and lossy) of the same image run through ImageOptim on macOS. Doing both of those took me less than 2 minutes, combined. And while the output of ImageOptim’s lossy compression isn’t near as sharp, it’ll still be “good enough” for most folks.

    At the end of the day, Guetzli’s output is really nice. And it does do a great job compressing things. I saw anywhere from a 74.63% to 89.28% decrease in size from my original image with very few visual artifacts. In its current form, however, it takes way too long to act as an efficient enough batch processor for small, independent publishers.

    So don’t go throwing away Kraken, Imagify, or Smush just yet… Especially if you post a lot of galleries. 😀

  • 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.

  • DuoTone Themes for Atom

    DuoTone themes – Syntax themes for Atom
    simurai.com

    While I’m normally a Solarized Dark guy — seriously, I’ve Solarized Dark’d all the things on pretty much every computer I touch — these Atom syntax themes are really pleasant.

    duotone-dark
    duotone-dark-sea
    duotone-dark-space

    I’ve been looking to change things up lately, so I’m going to try living with darkSea for the next month. I’ll let y’all know how it goes!

  • Podcasting Preflight

    After guesting on a few podcasts over the past year, I’ve come up with what I feel is a simple (but thorough) preflight checklist of the things that I like to do to before recording. These things help normalize my environment and minimize the majority of technical difficulties that I run into.

    Anyway… In an attempt to be helpful, I thought I’d share them with y’all.

    • Pour yourself a large glass of ice water.
      • Don’t accidentally leave it in the kitchen!
    • Plug in USB mic.
      • Select the USB mic as your input device.
    • Plug in headphones.
      • Verify that headphones are set as your output device.
    • Manually restart your residential gateway or cable modem.
    • Manually restart your router.
      • If an ethernet connection is available, plug your machine directly into your router.
    • Run a speed test on your connection.
      • You want low latency and a reasonably speedy connection.
    • Pause syncing on Dropbox.
      • See also: Google Drive, BitTorrent Sync, etc.
    • Change Backblaze schedule from Continuously to Only when I click <Backup Now>.
      • See also: CrashPlan, Carbonite, etc.
    • Halt all Vagrant development environments.
    • Enable Do Not Disturb mode in OS X’s Notification Center.
      • Want a shortcut? Option+Click the Notification Center icon.
    • Make sure that Shush is running.
    • Load Skype or Chrome.

    While I’m sure that some of this — especially the part about restarting my residential gateway & router — is just nerd voodoo, I haven’t run into any major issues after implementing this checklist.

    I’d love to hear about anyone else’s pre podcast routine. If you have one, please share it!

    P.S. If you’re not familiar with Shush, it’s an app that allows you to discreetly mute (or unmute) your microphone with a hotkey. Should you be recording in a location where children or pets are present, using its push-to-talk functionality can knock down a considerable amount of background noise.

    P.P.S. For podcasts that are recorded via Google Hangout, I keep a clean copy of Chrome Canary installed on my machine. I run Canary separately from my main browser, and have not installed any additional extensions. While loading the Hangout URL in an incognito window might have a similar effect, I find doing this leaves less to chance.