Today on Twitter I was remembering that one time when an @OReillyMedia software book said that some code I’d written was “definitely worth a look.”
It started as a project for an internship at a local ISP, where they had a need to quickly browse, search or update a certain database using a web browser. I threw it together in a few days using Perl and the data dictionary info offered by PostgreSQL (and later MySQL and Oracle)
I called it DB_Browser, and it was basically what PhpMyAdmin became, but abstracted out enough to use with any of those three database systems. (Solid database abstraction layers used to be a real thing!)
It was almost certainly full of security vulnerabilities, relying entirely on the use of .htaccess rules to prevent total chaos. The UI was as ugly as sin, the code not much better. But it worked, and I believe it was used in some form until the ISP was acquired years later.
I took the time to package it up and publish it. I think I put it on “Freshmeat,” a site that was just a feed of newly released software, back when you could even try to track such things. It started getting downloads and people started using it.
I’ve started using CiviCRM for an organization I’m working with. If you’re not familiar with it, it’s an open source constituent relationship management tool for not-for-profits, political organizations and other entities that might have a need to manage relationships with supporters, volunteers, donors, members and so on.
I’ll try to reflect more soon on the process of getting started with CiviCRM; it was a little rocky. But to get myself familiar with CiviCRM’s inner workings, I decided to write a simple extension that would allow the organization to get Slack notifications when certain objects (contacts, contributions, pledges) were created or updated. I couldn’t find any similar existing extensions in their directory or in my searching.
Here’s the settings screen:
(with apologies for the weird extra bullets, can’t seem to make them go away yet) and here’s what a resulting Slack message might look like:
The extension is available on GitHub. I’m sure there are many ways to improve it, so issues and pull requests are welcome.
Update on April 20, 2021: the extension now provides a more flexible CiviRules action for Slack notifications instead of a standalone notification method, so some of the above information is outdated.
I recently switched from using a Mid-2015 15″ MacBook Pro to a 2020 13″ MacBook Pro with Apple’s Silicon M1 chip. It was a Big Deal in the sense that my computer is a primary daily tool in my personal and professional life. So much of my work, my creativity and the management of my life is handled through this one device, so it’s always a little scary to make a change. (I actually could have been happy continuing with my previous laptop if its battery hadn’t been expanding, causing the entire computer to bulge in weird and alarming ways.)
Here are a couple of things I observed in making this transition and in using the MacBook every day since:
Apples to Apples
My previous MacBook Pro was pretty high end (2.8 GHz Intel Core i7 Processor, 16 GB 1600 MHz DDR3 RAM, Intel Iris Pro 1536 MB Graphics, 1TB HD) and very fast for the things I used it for. These included software development, hosting multiple software development environments, audio and video editing and rendering, graphic design and photo editing, and LOTS of browse tabs. It took everything I could throw at it and I never felt slowed down by the computer itself.
So the idea of “downgrading” to a smaller screen (13″ instead of 15″), fewer ports, and the same amount of RAM but 5 years later was a bit nerve-wracking. Conventional wisdom for a long time was that 13″ MacBook Pros were fine for some kinds of advanced computing but that the 15″ model was always the best option for the kinds of things I use it for. Maybe this was just me naively buying into Apple’s marketing, but it seemed to be supported by testimonials from colleagues over the years, and was a strong narrative in my head nonetheless.
But I’d heard and read that the Apple Silicon M1 chip was a game-changer, and that any comparison between Intel and the newer processors was not really valid. And after seeing enough stories from real users where they said the new chip plus 16GB of RAM was even faster running some of the same software I do, even with Rosetta 2 translation turned on, I was sold.
A couple times per year, WordPress plugin authors and owners get an email like this one:
WordPress 5.6 is imminent! Are your plugins ready?
You’re receiving this email because you have commit access or ownership of existing, open plugins hosted on WordPress.org. The next release of WordPress, 5.6, is scheduled for 08 December 2020.
We would like you to take this time to review your existing plugins and ensure their ongoing compatibility with WordPress. Once you’ve done so, you can update the readme “Tested up to:” value to 5.6. This information provides peace of mind to users and helps encourage them to update WordPress.
Here are the current “Tested up to:” values for each of your plugins:
The message goes on from there to list the plugins I’m responsible for and some notes and details about what’s new in the upcoming WordPress release.
In case it’s not clear, this is an important moment because the authors of tens of thousands of WordPress plugins are being asked to help ensure that when the many millions of WordPress sites out there upgrade to the upcoming release, that those sites continue to look and function as expected by their users. It’s an impressive example of how the WordPress developer community works together in the background to help sustain and grow the larger WordPress ecosystem.
For authors of widely used plugins, by the time this email goes out their plugin may already be fully ready, especially if they’ve been following or maybe even contributing to the development of the new WordPress core release. Some plugin authors rightly have an extensive automated test suite in place to confirm that every part of their plugin’s functionality works against the latest beta or release candidate version of the new version before it comes out.
Authors and maintainers of smaller plugins (like me) may not have the same infrastructure set up, and instead need to perform some manual testing of our plugins to ensure they’re ready.
So, here are the steps I follow every major release cycle to make sure my plugins have been tested and are ready for the new version.
Auto-updates for WordPress themes and plugins were released this year in WordPress version 5.5. They allow WordPress site owners to opt-in to automatically have new versions of plugins and themes installed when they are released, without any intervention from the site owner.
If you use auto-updates, one question might be on your mind:
How long will it take between when the author of a plugin releases a new version and when that new version is installed on your WordPress site?
This question is vital for site owners and managers. Especially in scenarios when new plugin or theme versions contain critical security fixes, time is of the essence to avoid possible unauthorized access to your WordPress site.
To get to the answer, let’s first review how plugin and theme releases happen.
The Plugin and Theme Release Process
When a plugin or theme author is ready to make an update to their software, they upload those changes to the directory on WordPress.org. This is where the code for their theme or plugin is hosted publicly.
Most theme and plugin authors also indicate the release of non-trivial changes by increasing the version number associated with their plugin. Maybe it’s a small “point release” like going from version 1.1 to version 1.2, or maybe it’s a major release like going from version 3.0 to version 4.0. The change in version number lets everyone know that there’s new functionality and fixes available. It’s a convenient way to refer to how software has changed over time.
Once the updated software and version number change is live on WordPress.org, it’s immediately in effect for new installations of that plugin or theme. Anyone downloading and installing a plugin or theme from that directory will now be using the latest code made available by the author.
But what about existing sites that already have that theme or plugin installed? How do they learn about the new changes and new version?
How WordPress Sites Discover Updates
You might think it happens through a “push notification” sent to your site from WordPress.org. But the WordPress.org systems would have to contact thousands or maybe millions of sites to tell them about an update to a single plugin. That’s just not practical.
In June of this year, I had an idea for a software-as-a-service (Saas) application that I wanted to build and launch. On July 1st, I committed the first lines of code to a git repo for the app. After about 200 hours of development time, on August 10th I launched the first version of the application into the world, ready for users and subscribers.
The service is called WP Lookout and you can read more about the service itself and why I built it on wplookout.com. This post is about the process, tools and services I used to build and launch a SaaS application in what felt like a relatively short period of time.
Here’s the short list of resources I used along the way if you just want to explore them without further commentary:
MailerLite for handling new user onboarding and marketing automation
I’m not going to go in-depth on all of these tools, as some of them are pretty simple and self-evident in their value. Others are just magical and deserving of some additional observations. Here are some things that stood out and what I learned along the way:
Disclaimer: I am not affiliated with Harmonizely and they did not ask or pay me to create this plugin, I’m just a fan of the service who wanted to create more ways to use it within the WordPress ecosystem. This post does contain some referral links where I may receive a small percentage of any sales that might result from readers clicking through.
There are a growing number of options to handle appointment scheduling, and if you’re in some field where people schedule things with you a lot (consultant, agency, counselor, accountant, lawyer, healthcare professional) I hope you’re looking at those tools to save you some time. One of the main reasons I like and settled on Harmonizely is because they support the open CalDAV standard for calendar connections and syncing, where as many other services only support Google Calendar or other proprietary connections. (This is especially important to me as a part of advocating for an open web.)
I also like Harmonizely because the service is simple and fast, they regularly release improvements and new features, they have a small and responsive team, and they’ve made their product roadmap public and interactive. Their basic tool is free and they have very affordable pricing for an upgraded version.
Creating this plugin to work with WooCommerce means that anyone who has an existing WooCommerce-powered store can add booking functionality in and keep using their existing payment methods, plugins and other settings. I can imagine a content creator who already sells access to video courses or other educational resources might enjoy being able to let users schedule a quick call with them for a small fee, too. Or maybe someone who offers troubleshooting services of some kind can now give their customers a quick way to pay for and schedule an appointment. There are lots of possibilities, and WooCommerce offers tons of flexibility so you can integrate with Stripe, Paypal, Square and other payment processors.