CASPAR.green

That's just, like, my opinion, man.

Custom Quote List Extension for WooCommerce: Part 1 – Setup

by Leave a Comment

This part 1 in a series of posts documenting how I coded a Custom Quote List Extension for WooCommerce. For background, see the Series Introduction.

What I’m going to cover here is how I set up my development environment, configure the plugin’s PSR–4 autoloading and pull in my development dependencies with Composer. In short:

  • Customizing Local by Flywheel for running WP Unit Tests.
  • Mapping the WP Unit Test Suite into PHP Storm’s external libraries.
  • Setting up Composer.

Let’s start with laying out my current development toolset.

  • My hardware is a Late 2013 MacBook Pro.
  • I use PHP Storm for my IDE.
  • I also keep a terminal window open for unit testing and generally use the Tower 3 git client (although there are some things with git that are better done in the terminal, too).

When I’m developing for WordPress I use Local by Flywheel. Local makes it easy to spin up a WordPress development site in it’s own Docker container. It provides for all the overhead of swapping out PHP versions and switch between Apache and Nginx environments. I’ve used Mamp, VVV, and ServerPress’s Desktop Server. Any of these is perfectly adequate.

Setting Up Local By Flywheel

As much as I like Local, there are a few extra things to consider when developing plugins, especially when unit and integration tests are involved.

  • When running things (like unit and integration tests) we need to run them within the Local’s Docker container for the site. (Open an SSH connection into the container from the Local app, right-click the site name and “Open Site SSH”.
  • Local automatically creates mappings from the container to folders on your Mac for /app, /conf, and /logs. In addition to those, in order to access the WP unit tests from PHP Storm we’re going to install in the next step, we need to create a new volume mapping. This requires installing the “Volumes” add-on for Local. Follow the instructions on that page to install it. Once you have it installed you’ll find a new menu item under your site for Volumes. Click into it, and you can add a new mapping. Enter /Users/Yourname/where-your-local-sites-are/site-name/wp-tests into the host field. The container destination will be /tmp/wordpress.
  • When setting up a new project, I run Kees Meijer’s setup-phpunit script in the new site container. Copy the script into the site’s /app volume however you like, but be sure to run it from within the Local Docker container’s terminal. Go to the /app (cd app) directory, then run with bash setup-phpunit.sh. This installs Composer and the WP unit test suite into the container.

Setting Up PHP Storm

Now, if you’re using PHP Storm, you can add the WP Unit Test suite to the project’s external libraries and have all the testing functions be recognized for auto-completion and all that other good stuff.

Setting Up Composer

I’m not going to spend a lot of time here with the How-to of Composer. There are lots of other resources for that. Here are the important parts to include in your composer.json file:

"autoload": {
    "psr-4": {
        "ICaspar\\WcQuotesList\\": "src/"
    }
},
"autoload-dev": {
    "psr-4": {
        "ICaspar\\WcQuotesList\\Tests\\PhpUnit\\": "tests/phpUnit/",
        "ICaspar\\WcQuotesList\\Tests\\PhpUnit\\Unit\\": "tests/phpUnit/unit/",
        "ICaspar\\WcQuotesList\\Tests\\PhpUnit\\Integration\\": "tests/phpUnit/integration/"
    }
},
"require": {
    "php": "^7.1",
    "composer/installers": "^1.0"
},
"require-dev": {
    "brain/monkey": "^2.2",
    "phpunit/phpunit": "~6.5",
    "roave/security-advisories": "dev-master"
},
"scripts": {
    "test-unit": "\"vendor/bin/phpunit\" --testsuite unit --color=always",
    "test-integration": "\"vendor/bin/phpunit\" --testsuite integration --configuration tests/phpUnit/integration/phpunit.xml.dist --color=always",
    "run-tests": [
        "@test-unit",
        "@test-integration"
    ]
}

I require PHP 7.1+ for my projects since 5.6 and 7.0 will both be “end of life” by the end of 2018. Other dependencies I’ve pulled in here:

  • brain/monkey is going to allow us to mock WordPress functions (and will pull in Mockery and other goodies for mocking other things).
  • We’re going to need PhpUnit for our tests.
  • roave/security-advisories is something I use in all my projects. It alerts whenever there’s a security issue with any other dependencies I’m using.

Run composer install and you’re ready to go. So far, so good.

In the next post I’ll put together the plugin’s directory structure and get the first unit and integration tests up and running.

Custom Quote List Extension for WooCommerce: Introduction

by Leave a Comment

I wrote a new plugin this week. It’s a WooCommerce extension that adds highly customized “wish list” — actually an “Interested in a Quote” list — for a store that doesn’t do any online purchases.

Background:

Why an online store that doesn’t do online purchases? This particular client sells stuff in a highly competitive and price-sensitive market. Prices are volatile and can vary from one customer to the next depending on their holding particular government contracts or being part of certain sectors: healthcare, education, etc. So WooCommerce products are used for displaying products, but no price information is displayed and all the cart and checkout functionality is disabled. Instead, potential customers are directed to a “get a quote” form where they can indicate what they’re interested in. A sales rep calls back and takes it from there.

Without the WooCommerce cart, there has been no way for customers to easily select products, or compile them into a list. The client’s customers have to note their products on their own and then type them into the quote request form. We considered activating the regular cart without price functions and then modifying the checkout functions to send a quote request instead of an order. But because down the line the customer might actually want to turn on the cart and checkout for some products and keep other items on the “ask for a quote” basis, we didn’t want to hack the cart and cut off that possibility for the future. There had to be a way for both “products in a quote list” and products in a cart.

We looked at several “wish list” extensions already on the market, but they did way more than, and not quite, what we had in mind. We’d have to do major surgery on any of them to do exactly what we needed, so we decided to roll our own.

Process:

I’ve been doing a lot over the past year with Test Driven Development (TDD) and particularly as it applies to WordPress development. I wanted to apply all that I’ve been learning in this project. I wrote the unit tests first. I also wrote integration tests (sometimes concurrently with the unit tests before writing the code, sometimes writing a corresponding integration test as soon as the unit test passed), so the plugin has a complete test suite out of the gate. The extension is written completely in Object Oriented PHP using PSR–4.

The list works by inserting a new number input and “Add to Quote List” button to product detail pages. When the button is clicked it adds the item ID and indicated quantities to a cookie. On the quote request page, a script reads the cookie, grabs the product names via ajax, and enables the list to be inserted on the page using a shortcode. The list allows users to remove items and to update item quantities. The list is also inserted into a hidden form field on the page (and is updated whenever the user removes or updates a quantity) that gets submitted with the form. Finally, when the list is submitted, the cookie is cleared allowing the user to start again with a new list.

All these list operations are done with JavaScript. I’ve used ES5 for now. Sometime down the road, I’d like to revisit this and upgrade to ES6.

Sharing What I’ve Learned:

As I built this extension, I found myself having to solve a number of common problems. (I assume they’re common because they arose during the building of a fairly routine bit of plugin customization.)

For example:

  • Thinking through OOP architecture in a WordPress plugin,
  • Doing Unit and Integration Testing in WordPress,
  • Doing it TDD in WordPress,
  • Writing a plugin that depends on and extends another plugin,
  • Building an asset loader that can tell when it should load a minimized version and when it should load a development version.
  • Loading scripts only when you need them.
  • Doing ajax in WordPress.
  • Baking your own cookie.
  • Coordinating JavaScript activity on a page with the completion of an ajax (asynchronous) request that they depend on.

Over the next few weeks I’m planning on writing all of this up into a series of posts on how I did it. Not that anyone is going to want to do exactly what I did; this was a specific solution for a particular set of requirements. But maybe it will help someone (myself 6 months from now) who is dealing with some of the “common problems” encountered here. And, it’s also likely that someone may have a better idea how to approach and solve these things than what I did – and I’d be glad to know what I can do better.

Why Continuous Website Development Is Better for Small and Medium Sized Businesses

by

In my last post about content being hard, I mentioned that I’ve had a lot of web projects that seem to take way longer than they should. Most of the time, it’s because content is hard.

One of the problems with projects taking forever is that at a certain point the extra time erodes the project’s profitability. And that’s just one of the things that can turn a project sideways.

The larger problem with “building a website” is that a good website is never really finished. Building a website is (or ought to be) an open-ended venture.

There is that intensive activity at the beginning when you try to guess how much of a client’s vision you can accomplish on the budget they present. But even when the “build” is done, there are inevitably more things the client wishes might have been. There is the ever-present question of maintenance. There is making sure content (there’s that hard part again!) stays up-to-date.

And, if the business is really a going operation, there is always change. Meaning the online strategy needs to adapt, and the website needs to adapt.

Site owners respond to this in different ways. Some just “make do” with the site as it is, shoehorning everything into what they’ve got. It’s a frustrating way to go. Many bumble along trying to make the changes in house for as long as they can manage it. Then a few years down the road they have a royal mess and return asking for a new site build or substantial re-build. That starts the cycle all over again.

The problem with both of these approaches is that site owners invest a significant amount of capital into a site that immediately, like driving a new car off the lot, begins to lose value. It loses value, but not for the same reasons as the car. With a car, its the use, the wear and tear, that eventually ruins it. With a website, wear and tear isn’t the issue. It’s that the moment you say “done” and stop development, it’s standing still in a world where everything else is moving forward at breakneck speed. Four years from now the website will perform exactly the same as the day it was completed. But 4 years from now, in comparison to what’s customers will expect and the business will need online, the site will be miles behind.

Nearly every client I’ve worked with has experienced this. The website I build for them is not their first. I’ll ask them about their current site, and they’ll chuckle and say, “Well, a few years ago we had some other site, but it wasn’t what we needed, so we got this one we have now, and it’s not really what we need now, either.”

Sad to say, I’ve built quite a few sites for clients in that position, and now a few years later, the site I built for them “isn’t what they need either.” It’s not that I didn’t build them a great site. At the time, they were thrilled with it. But once I turned over the keys to them, it froze in time while everything else kept moving. They need a new site again.

It’s because websites are mistaken so often for a one-off major expense like a car or a piece of equipment. Maybe like a computer. Businesses that are successful online, though, realize that it’s not a one-off. It’s something that has to be constantly in development. Amazon would be a distant memory today if it stuck with the website it started with. Think of the businesses you enjoy visiting online. It’s because their site is not the same as it was last month that you keep coming back.

Big businesses have their own web development department – often several departments – working for them. Most small and mid-sized businesses can’t afford that. But what they can afford and should invest in is:

Continuous Website Development

For most small to mid-sized businesses, a few hours of ongoing development investment each month is enough to keep pace with business and technological changes. For some very small sites, it could be as little as a few hours per quarter beyond regular content, maintenance, security and backups.

Putting this in the category of continuous development investment, rather than “we have a website and we’ll get to it when we have a chance”, ensures that the site stays continuously at peak effectiveness for the business, and over time is more cost effective too.

Cost Comparison – A Typical Scenario

Say you’re a smallish nonprofit or business and you ask me to quote you a website. We talk about all the things you want it to do for you, and I’m able to quote you a reasonable amount of what you want for within your budget of $8000.

We get to work. We start with the design, which goes through three rounds of edits and takes a few weeks to hammer out. Then I build out most of the site over the course of a few weeks, say three weeks. We have another couple rounds of changes based on the staging prototype, and that takes another couple weeks of back and forth. Then I ask you for content, and it takes you another (optimistic, because content is always the hardest part) four weeks to get that to me, and with the content entered you decide a few other things need changed before launch.

We’re now just over 3 months in and there’s nothing online yet. And that’s provided everything goes smoothly.

After the site launches, you discover that you really do need some of those other things you thought about at the beginning, but trimmed from the project to stay within budget. Or you discover, now that it’s up and running, that you never thought of something that would be ideal for your business to have. You have to decide whether to invest in the additional costs to add on, say another $4000, or to do without. If you’re cost sensitive, you’ll probably do without, and already your site has less value than what you paid – frozen in time, its decrease in effectiveness has already begun! Or you invest the additional money and sometime next quarter you have something closer to what you want. But by then something else has come up. At some point, you say, “enough.” Until 4 years later it gets to the point that you really do need a new website all over again.

So, divide that total $12,000 investment into 4 years. That’s $3000 per year, or $250 per month. For a site that for the first 6 months isn’t online – so, really divide your money into 3.5 years: that’s nearly $290 per month – and the rest of the time leaves you frustrated that you can’t do a lot of what you’d want with it.

Not to mention, it’s a big hit every 4 years or so to plan for a new $12,000 expense. Large lump sums are hard on small businesses. I know. I run one. If you’re limited to what you can raise in a lump sum, you’re naturally limited in what you can do in any given generation of your website.

Compare that to a continuous development scenario.

Say, again, you’re a smallish nonprofit or business and you ask me to quote you a website. We talk about all the things you want it to do for you, and we agree to a Continuous Web Development Retainer, where for $300 per month, you get 4 hours of consulting, design and development time, every month, from now until we decide to call it quits, and we’re going to determine together, as we go, what needs to be built and in what order.

In the first month, we spend 2 hours hashing out what your initial priorities and strategy are going to be. We spend one hour putting up a simple website with the very basics to get your presence online, and we spend the fourth hour looking at initial design considerations. Now, in the first month, your site is already up, is accurate, and you’re starting to get found online (or at least you’re no longer living with the embarrassment of that old site you’ve been cringing at for the last year).

You are online by the end of week 2!

In months 2 and 3, we spend less than an hour on planning, since we already have a plan, We spend 3.5 hours each month on design, A/B testing what you like and don’t like as we go. Meanwhile you’re adding content to the small initial site that immediately enhances your online presence. As you add content, you start to get a 1st-hand feel for what elements of your site are more important to develop sooner, and what can wait.

By Month 3, your site is growing, and the design phase is taking shape. At this point, you’ve spent only $900 of the $8000 you originally budgeted.

In months 4–6, we continue to develop the design. As different design components are solidified, we work them into the live site as we go. Meanwhile, because it’s on your front burner, you continue to add content that keeps your visitors coming back.

By the end of 6 months, your new site is still in its infancy, but it’s solid, it represents your business well in its design and content, and you have a very good feel for what needs to be added next. And you’ve only spent $1800 of the $8000 you initially thought you might need.

By now you can see where this is going. At the end of 3 and a half years, the same amount of time a one-off build would actually have been online, you’ve paid the same $12,000 you’d earmarked as that first lump sum, plus additional cost overruns.

The difference is you’ve had a site that has been an effective and growing part of your business. You’re not going to have to come up with another $12,000 wad to replace it next year. Instead, you continue to develop it, building on what you have. Getting better and better each month.

Having developed it in the direction it needed to go as needs arose, it long ago has become a monthly investment that more than pays for itself.

Look at you! Your business is actually making money online!

Granted, it’s not as flashy as a “big reveal”, but in websites, as in life, slow and steady wins the race. Drip by drip, month by month, without large outlays of cash, you build an asset that pays you back.

The hardest part of building a website is the content.

by

I’ve built a lot of websites for a lot of different kinds of clients. I’ve worked with small non-profits and churches, industry leaders and international security system distributors, and everything in between. From the smallest to the largest, from the simplest to the most complex, the most difficult part of every project has never been the technology. The most difficult thing is always the content.

As I write this, I have 2 websites for which everything is ready to go. The custom designs are implemented. The custom functionality is working. But the sites are not live. In both cases, I am waiting for the content. One has been waiting for close to 3 months; the other close to 1 month.

I launched a site last week. That site was 2 years in the making. Actually, though, it was ready to go nearly a year ago. It took a year to create the content.

Beyond the initial website launch, content continues to be the hardest part of ongoing maintenance. The most common issue I’ve seen with websites (and not just the ones I’ve built) is that content is outdated. Calendars of events with the most recent event several months to a year or more in the past come readily to mind. Or About pages with a “Welcome Letter from the Executive Director” touting organizational happenings just prior to the site launch three years before.

It’s not anybody’s “fault” in particular. It’s just that content is hard. So it’s often the last thing to get done and the first thing to get put on the back burner.

Sometimes it seems like the only way to get content in a timely manner is to make the cost of not providing the content explicitly higher. If keeping sites on a staging server cost a small business $100 per month, that might be enough of an incentive.

I’ve known developers who approached it as more of a carrot than a stick by offering a $1000 discount on the site build if content gets provided on time. (Of course, that $1000 discount is built into the estimate beforehand. But at least when the content is late, the developer doesn’t get holding that slot open in the production schedule without some compensation.)

I’ve also seen contracts that say when content is late by a certain number of days the project goes into “dormant” status, and then require a significant “reactivation fee” to get back on the schedule.

Some clients, clearly, need a lot of help with content creation. When that’s the issue, a content creation retainer of some sort may be in order, provided a developer has the resources to create content. This seems like something an agency might be more apt to offer. Not all developers (even very good ones) can write in complete sentences, or in a way that can make any subject at hand seem interesting. And poorly done content is no service to anyone.

So, what’s the point? Merely this:

Given that content is always the hardest part of a website, any website project needs a plan to make sure that its gets done, and gets done well.

If you’re a developer, it means possibly even having all the content in advance, before the first line of programming gets written. Or at least having a strategy for making sure it’s on its way.

If you’re contracting with someone for a new site, it means having a plan in place to get the content done. Have someone who is responsible for it, not just during the initial building of the site, but as an ongoing priority to keep content up to date.

There’s no silver bullet for this. Content is hard. It is also king. Nothing on the web goes anywhere without it. Have a plan for it. Work the plan for it. I guarantee that when you do, your website will be better than your competition. Why? Because they probably have a letter from their CEO about what they were doing 3 years ago on theirs.

Bye Bye Facebook

by

At the end of this week (specifically, on March 23) I’ll be deleting my Facebook account. Not just “taking a break” from it. Deleting it. Or at least, as much of it as Facebook will really delete.

On March 17 it came to light that Facebook has been allowing companies to collect profile data without users’ knowledge or consent, and that this has been going on since at least 2014. Facebook has spun this as not a security breach (though it is). And even if you buy their version, it’s almost worse, since it’s been a matter of policy by which Facebook has profited from the betrayal of its users. This story in the Guardian is a comprehensive enough description of what happened. There will probably be more details as investigations get started, but don’t expect Facebook to be exonerated.

What’s the big deal?

If you think you’re not one of the 50 million people whose every post, social connection and personal information isn’t available to the highest bidder, think again. This was targeted at Brits and Americans. If you have ever seen any of your “friends” post an “I took this quiz and here’s what it said” post, your information has been given to the people behind those quizzes, regardless of your privacy settings — because Facebook allowed them to get profile info of every friend of the person who took it.

There’s a saying in internet business: “If you’re not the customer, you’re the product.” What that means is that if you’re not paying a company like Facebook for the services you receive, it’s because that company is making money by giving their real, paying customers access to you.

Advertisements, for example. If Facebook can attract lots of people to their network and have you and millions of other people spend lots of time on their site, advertisers will pay Facebook to show you their ads. We’re familiar with this kind of thing. Newspapers and magazines have been doing it for years. And we can decide whether to spend much time looking at those ads. And back in the day, newspapers and magazines would sell your name and address to other advertisers that would send you junk mail. Remember junk mail? It was an inconvenience. We all made fun of it. We complained about it as we threw it away. But still, you could throw it away in the privacy of your own trash can, and the advertisers were none the wiser.

Unlike newspapers, companies like Facebook track how much time you spend looking at ads, whether you click on them, even whether you hover your mouse over them as if you’re tempted to click on them but don’t. Over time, they collect a staggering amount of data about you. They sell that data to advertisers. When they’re honest, they don’t sell the actual data. They sell paying customers the use of their algorithms, their data processing programs that sift through that data, which “targets” you with particular ads you’re more likely to click on. When they’re honest, their paying customers don’t actually get to see your data, and they don’t get to run their own targeting software on the data. When they’re honest, “what happens on Facebook, stays on Facebook” (or whatever service it may be). If you’ve signed up and agreed to that mile-long “terms of service” legalese, you’re agreed to that kind of bargain. You’ve decided that the benefits of having online “friends” or playing Candy Crush is worth the online junk mail you’re going to get.

But what Facebook did is actually give your data to other people and let them run their own data mining software on it. You and I didn’t agree to it, and in spite of assurances about privacy policies and security settings, didn’t have any control over it. In fact, those settings were an elaborate hoax designed to make us think we had control over who gets to see our stuff when in reality anyone willing to pay could have anything they wanted on us. (Well, Facebook will probably say it’s covered in their terms of service, but it will take a staggering amount of money to sue them about it.) And those companies that now have that personal data about you and me can, in turn, sell it to anyone whose buying.

Hit them where it hurts.

It’s one thing to decide for yourself that you’re going to trade off some of your personal data in exchange for the privilege of catching up with old friends online. I’ll agree to allow a company to offer access to my eyeballs for their ads if the service they’re “giving” me is worth it. But I refuse to be a cash cow for a company that over the past couple years has shown itself to be unscrupulous about trading my trust for their bottom line. I’m pulling the plug.

I know that I’m just one. My exit from Facebook isn’t likely to cause the company to suffer catastrophic loss of revenue. But at this point, it’s simply unethical to participate in a network that is, at it’s root violating the trust of its users. What might I do (take a quiz? click an ad?) that inadvertently exposes all my “friends” to loss of privacy, or worse? What might I post, thinking it’s “just for friends” that may some day end up being used against not just me but others, in unexpected ways?

To all my friends, I will miss seeing the pictures of your cats and children in your feed. Fortunately, there are still other ways to stay in touch, and I hope you will. My best advice to you is to get out while you still can. Don’t be a body in a bag somewhere in their Matrix, being sucked dry while they keep you locked in some kind of dream world. Get off your screen and take your dog for a walk. You’ll be glad you did.

Top 10 Posts of 2017

by

Yes, it’s March. Yes, this is an indicator of how often I look at my blog statistics. But for the curious, here are the 10 most viewed posts last year. (Not all of them were written in 2017.)

  1. Vary the WooCommerce Product Archive Grid by Category vs Subcategory
  2. CodeKit vs. Gulp
  3. I’m Caspar Green
  4. How to Use WooCommerce Without the Cart
  5. Updating to El Capitan Breaks Vagrant
  6. Home Renovations: Stairs and Front Hall
  7. Using jQuery Masonry for WordPress Responsive Widgets
  8. Ems, Rems and Px: And One Sass Mixin to Rule Them All
  9. I Threw Away my Magellan GPS
  10. Namespacing and Class Autoloader for WordPress Themes

iCaspar Analytics Plugin Update

by

Over the past week I’ve made a couple updates to my iCaspar Analytics plugin.

The main change removes the input for the Google Analytics key from the Customizer, leaving it just on the “Settings > General” admin page. Because one go-to place for the setting is better, and site statistics don’t have anything to do with the way a site looks. (Well, your stats are probably going to be lower on an ugly site, but so far as the technology is concerned they’re not related.)

There are also a couple things that are a little cleaner “under the hood”.

Download the update.

Recently Edited Pages Dashboard Widget

by

I’ve sometimes posted blurbs about books I’ve been reading. Earlier this month, for the new year, I started a new page with an single list of books for 2018 to keep track of all of them in the same place.

The WordPress dashboard has a handy list of recent and upcoming posts, where as soon as you log in you can single-click to edit the 5 most recent posts and the 5 nearest upcoming posts. But there’s nothing out-of-the-box for pages. (It’s assumed that pages are mostly content that doesn’t change very often.)

It stands to reason that the most recently edited pages on my site are the ones I will most likely want to edit again. (The Least Recently Used, or LRU, caching algorithm!) And so it is with the books page, every time I want to update what I’ve been reading (a couple times a week) I have to click into the full listing of pages and then hunt down the books page. The next most recently edited (and true to the algorithm’s prediction, the next most often edited) page is my “About” page.

The Books page, being fairly recent, is near, but not at, the top of the full list where I’d like it to be. The About page, though, since it was one of the first pages I ever created, is near the bottom. Scroll, scroll, scroll. Yuck.

Then it hit me: I want a 1-click link to edit pages, too! The 5 most recently edited pages ought to do 90% or more of the time I want to edit a page.

So I built a little Recently Edited Pages Dashboard Widget. Why not? A little Sunday afternoon project to exercise the brain!

Ever want a 1-click link to edit recent pages? Download the plugin! (Requires WP 4.9+ / PHP 7.1+) Or, if you’re curious about building a little dashboard widget of your own, take a look at the code on Github.

Online Security, Meltdown & Spectre: Do What You Can

by

Last week came the report that there are bugs in the processor chips that run pretty much every computer that’s been built in the past 10 years. Maybe more. Meltdown and Spectre.

Two days after I first saw it come across my Twitter feed, NBC Nightly News reported it. They made it sound like it was mostly Apple products that were affected. It’s not just Apple. It’s just about anything with a processor chip in it.

I’m not a computer security guru, nor do I pretend to be. Here’s Randall Monroe’s explanation that’s as good a high-level view for ordinary people as it gets:

xkcd explanation of Meltdown and Spectre

Obviously, these security holes are cause for concern. But there’s just not a lot that most of us can do about them. It’s a problem for other people smarter than us to figure out.

For the rest of us, there are things we can do to make life with computers slightly less risky. There is low-hanging fruit that is easy enough to grab, that can go a long way.

Start with passwords. (I’m talking to “Joe Average” readers.) If you don’t have a password manager, you should.

  • Stop using the same password for everything. If one site gets hacked, you’re pretty much screwed on all the sites you use that password for.
  • Stop using easy passwords. Longer passwords are better. Passwords that are single words you can find in the dictionary are pretty much the same as not having a password at all.

Of course, you can’t remember all those different and long passwords. That’s why you need a manager. I use and recommend Dashlane. I’ve tried LastPass and hated it. (Like it says in the masthead, it’s my opinion.) I can’t say anything about the others. But having one is better than not having one, because you start using better passwords.

For those of us who are developers, know the basic security concepts of the language you’re programming in. For PHP developers, here’s the page to bookmark for your 2018 PHP security reference courtesy of the people at the Paragon Initiative. (Hat Tip to Cal Evans at Nomad PHP.)

While you’re at it, here’s a story from David Gilbertson at Hackernoon that will help you understand the importance of taking some time for due diligence with the code you’re probably importing from other people’s repositories.

All this to say, there are some things about computer security that, by and large, are beyond us ordinary folk. But there’s a lot we can do to avoid the vast majority of threats that aren’t sexy enough to make the national evening news.