Table of Contents

Title
Content
Disclaimer

Colin Michael Lucien Jonathan Nelson’s Blog

https://cmljnelson.blog/?post-type=post&taxonomies%5Bcategories%5D%5B%5D=18&dates%5Bafter%5D=&dates%5Bbefore%5D=&show_title=1&show_url=1&show_date=1&show_featured_image=1&show_content=1&printout-meta=on&post-page-break=on&columns=1&font-size=normal&image-size=full&links=include&rendering-wait=200&print-my-blog=1&format=ebook

Colin Michael Lucien Jonathan Nelson’s Blog

The Longest Name in WordPress

Posts with Category: WordPress, from https://cmljnelson.blog.Printed on August 15, 2019 using Print My Blog

My WordCamp Vancouver 2016 Experience

https://cmljnelson.blog/2016/08/28/first-blog-post/ August 28, 2016

5 minute read
Went to my first WordCamp yesterday (a conference for WordPress users, and WordPress is software that runs blog’s and websites like this one).
I was actually all ready to go last year too (I bought an early bird ticket) but I had recently re-dislocated my shoulder again, and the date for surgery was the day before WordCamp. What’s more, while recovering I was attached to some ice machine for reducing swelling. So I was stuck at home, and all I could really do well was sit in front of the TV and play “out of this world” on Super Nintendo.

Getting there

Getting to WordCamp was an adventure. Normally, from Shawnigan lake, I’d have to drive for ah noir to Nanaimo or Victoria, wait for about 40 minutes go board a ferry, ride on the ferry for 90 minutes (I always enjoy the sailing though) then drive for about an hour through traffic to downtown Vancouver: about 4 hours one way, and that’s assuming you can catch a ferry when want. Arriving at 9 am at BCIT downtown Vancouver was going to mean leaving at 5am, and getting from to help with putting kids to bed for 7pm was going to mean leaving the conference at 3pm (actually earlier with ferry schedules). And round trip this would be about $200 (fir ferry, gas, and parking).
Instead I discovered I could take a Harbour Air sea plane from Maple Bay (30 minutes away) which would get me to downtown Vancouver in an hour, and BCIT was only a 10 minute walk away. It cost about $250 round trip, but it was so much more convenient, I could attend much more of the conference, and it was a nice adventure.
When I arrived at the Maple Bay Marina at 6:50 I struggled a bit to confirm at which dock I should wait for the sea plane. I saw no sign and the online instructions didn’t help (their directions mentioned landmarks which I also couldn’t find, instead of just using the dock letters which were clearly marked).
At one of the docks, I saw a Harbour Air sea plane, but it was so tiny I assumed it must be a different one. It looked like it only had space for the pilot.
So I wandered around, asked some lady walking her dog (didn’t ask the guy complaining that the washrooms were closed), called up Harbour Air headquarters (they weren’t open yet), and double checked their website. Although I arrived 20 minutes early, by 5 minutes before takeoff I still didn’t know if I was in the right spot.
Them I heard an engine running, which sounded like a sea plane, and followed my ear. I hopped onto a dock (which said to not trespass) and about 100 meters off, at the end of the dock, I saw the sea plane pulling up. Phew! (And yes it was the same tiny one I saw earlier, but at a different dock).
I showed the pilot my ID (didn’t drop it in the water!) and hopped in. I reminded me a bit of squishing into the back of a pickup truck where they have this two tiny sideways facing seats only kids can fit into. It wasn’t that bad though.
The pilot was friendly, and showed the one other passenger and I the safety video from an iPad (“the most high tech piece of equipment on board”). It was actually amusing and informative. The narrator told the passengers to turn their phones off, and when one didn’t comply, tossed it overboard with a “plop!” Also, it pointed out that the tiny plane actually had 6 exits (my first reaction was to think that was also a joke): two in the front by the pilot and copilot, and two in the middle on each side (one I entered through), and each of those doors also had a kick-out window (oh and the doors could be opened as easily as a car door).

Taking off was a smooch nerve wracking, but mostly fun. We made a stop on Saltspring Island (2 hours by driving, waiting, and ferry) but 5 minutes flying. The pilot did a nice tight turn in approaching the docks and I could kinda feel above-normal G forces.
The whole flight was really picturesque and enjoyable (once I got over the idea that I could open the door and fall a kilometer to my doom).
So an hour after (1st) takeoff I was in downtown Vancouver, wandering past the sky scrapers, making my way to WordCamp.
What happened there

Checkin was nice and easy (thanks to volunteers!) I’m actually pretty happy to get the t shirt, and my 3 year old will love the stickers.
Luckily I got off on the right foot. I got some muffins, and started chatting with basically the first person I found: Doug Rider. He was friendly and interesting. Iirc he’s basically retired from being some kind of music recording technician in LA to building WordPress websites in Portland. I learned the term “hamburger menu” from him, and actually about ancestor.com’s DNA testing for family history. (It was a little funny because he also got into mentioning “and actually there this church, the church of Jesus Christ of Latter Day Saints, that’s really into family history. They’re into some pretty weird stuff, like admitting people into their church after they’re dead, but they’ve got a bunch of nice resources…” I sorta had to interrupt him to let him know “ya know Doug, I’m actually a member of that church”).
The first presentation I attended was “how to not design like a developer” by Tracy Apps. It was interesting hearing about a bunch of tools to make web design more easier for works without an artistic bone in their bodies. One I took note of:

- kuler.adobe.com for telling you what colors compliment each other and go well together

- desinion.com for evaluating and comparing design option

- subtlepatterns.com for getting classy textures for website backgrounds

- http://getbootstrap.com is a design framework (I think I heard of it, but basically didn’t know any details), that apparently works quite well with WirdPress too: use bootstrap to design your layouts, then pick out the pieces and put them into WordPress theme template files, et voila, you have a new custom theme built in bootstrap, that works great on different devices

- wrapbootstrap.com has some specialized bootstrap stuff for WordPress

- google fonts has a tool for picking fonts that look good together

- svgeneration.com for creating backgrounds from SVGs so they’re both fast and derailed

- snap.svg for really cool things you can do with JavaScript and SVGs

And there was more I didn’t take note of. But hearing of all these tools certainly makes design much more approachable for boring folks like me.
Another presentation I really enjoyed was by Andrew Taylor about diagnosing site performance with New Relic.
He gave a concrete case study to show how to improve a site’s performance drastically.
The example was of a site running woocommerce, with a page showin 25 products, their terms and taxonomies, and a Twitter feed.
He showed the sites initial performance: about 2 seconds per page load. He used New Relic to analyze how much of the request was used by PHP, MySQL, and external services.

- By caching the Twitter feed results for a few minutes, the wait time for external services basically got reduced to zero

- By upgrading PHP from 5.6 to 7, it took off about a quarter of the PHP load time

- By using an object cache, he avoided hitting the database and dropped MySQL time to almost zero

- By using “require” instead of “get_template_part” in his template code, he further improved PHP time significantly

- He switched to using a full page caching plugin to basically reduce all the request to nearly 0.2 seconds (except when the cache expired)

- He used a CDN to deliver media, CSS and JS files much more rapidly

- He converted the site to use HTTPS so that it could support HTTP2 which supports “multiplexing”

- Also, by using a service like Elastic Search, he got better search results (there are WirdPress plugins for this) which I think were easier on the database

Those were probably the best presentations from WordCamp for me.

Two kinds of Infinity

https://cmljnelson.blog/2016/09/04/two-kinds-of-infinity-at-work/ September 4, 2016

2 minute read
At the recent WordCamp I attended, one of the speakers mentioned how when you’re working on your own website or software, you’re never “done.” There’s always some way to improve it (also, there’s always some new bug you never noticed before, and some integration that makes a change that breaks it.)
And that sounds about right with my work at Event Espresso. We’ve always got a new feature we’re working on. Or several. There’s basically an infinite amount of work to do.
I also have seemingly infinite time to do work. (Of course, both are actually limited to my lifespan and other stuff. But everyday I have more time to work, and also more to do.)
It reminds me a bit of some math class. If you have two lines on a graph (see this post’s image), both pointed towards the top-right, as you look further and further to the right of the graph, both lines continue towards infinitely. But, if one of them is steeper than the other, one of them may be “approaching” infinity faster than the other.
More recently, it also reminds me of trying to cleanup after my 3 -year old and 7-month old: they usually create a mess quicker than I can clean it up!
Even though both my todo list and got-done list are growing infinitely, it seems the former is growing faster than the latter: there’s not just only always more to do, but there’s more to do today than there was yesterday. And that can feel a bit discouraging, and it has some interesting consequences:

- I’ll never be “done,” even momentarily.

- It means there are some items on my todo list that will never even be started. My todo list is prioritized, and that means that anything with a low priority will never get done. So why do we keep them? I can’t think of any reason, other than that they might someday become high priority.

- When a new item appears on my todo list, I isually spend 5-20 minutes just assessing the feasibility of it. If I’m able to complete the task in an equal portion of time, I’ll usually do it right away. Because otherwise, it will get put into my backlog, and then never get looked at again. So super/short todo list items can be done immediately, but everything else seems to never even get started.

- If a task isn’t doable in under 30 minutes, and it’s not high priority, it may as well never be created, because it will probably never be done.

Of course, if my todo list were growing more slowly than my got-done list, eventually my todo list would be empty and I’d temporarily have nothing to do. That would be satisfying for a moment, until I realized that means I have nothing to work on and therefore nothing more I can bill for. Oups. So that’s actually not desirable either.
So is it better for the todo list to grow faster, or slower, than my got-done list? I don’t know. Maybe I’ll have a follow-up post where I know.

Things to Consider Before Assigning Me a Task

https://cmljnelson.blog/2016/09/14/things-to-consider-before-assigning-me-a-task/ September 14, 2016

7 minute read
I do computer programming for work (php and python nowadays). It sometimes frustrates me, and I’m sure my employers too, how long seemingly simple jobs take.
Eg want to change a website’s font size? Seems like it should just take changing one setting somewhere from 10 to 11, right? Yeah that’s it…  but don’t forget to factor in that now areas of text take up a tenth more space and so now all the spacing everywhere next to text (so probably everywhere) needs to be adjusted, now some words are too big for mobile devices and so need to be fixed somehow, and there will probably be a dozen other small tweaks that need to be made or something will look strange. And that’s assuming I only need to edit one line of code to change the text size. In reality I’d probably need to change it in a dozen spots too. And let’s also not forget testing it on a variety of browsers, screen sizes, documenting the change, and, if I’m collaborating with a team, discussing the merits of the change, best practices, and different solutions.
So although it originally sounded like a trivial 5 minute change, turned out to be a 2 day change. Oups.
So sometimes my work is painfully slow.
So when I embark on doing some task, I want folks to realize that I will probably be working at it for quite some time. Even if the task only took a minute to conceive, it may take hours or days to execute.
And although they may be paying me for the hours regardless of how good the idea was, job satisfaction has little to do with the income and a lot to do with feeling like you’re making a difference. (If they told me they’d pay me double to dig holes and fill them in again, I’d probably still prefer to do what I’m doing now.)

What constitutes a Plan?

Does “change the website font size from 10 to 11” constitute a plan? It’s a command, not a plan. Nowhere in that statement does it show that the impact of this change has been considered. It doesn’t mention what the goal is, or how we will know if the change was successful or not. It doesn’t mention why that goal is even worth the effort. It doesn’t mention any prior experience you’ve had that led you to this “plan”. It doesn’t mention what alternative plans exist, which might equally meet the task’s objective in an easier way. It also doesn’t mention “prior art” (what others have done in similar situations).
So basically, it’s an idea that popped into your head with no specific goal, based on unknown experience (if any), that you haven’t considered what the impact would be, that may have a better alternative, that attempts to fix an unknown problem, which might not need fixing in the first place.
Well given that’s the situation, don’t be surprised if I’m not excited about doing it.

An Example Considered

Continuing with the font size change example:

- what is the problem this hopes to fix? Let’s say it’s that some users are having trouble clicking the menu links from their phones. But otherwise, every one can read the text just fine.

- What is the goal? Allow them to easily click menu items from their phone; but also continue to have the website usable from a desktop computer, and continue to have site layout be basically preserved

- How will we measure success? Most likely, the elderly person who was complaining they can’t press menu links from their phone should be satisfied; and the site should continue to look good for users from s variety of age groups and technical skills, and a wide variety of browsers.

- How important is this? It’s a bit annoying, but there are other jobs which are much more critical to the business. So if it can be done in under 3 hours, great; any longer and we’ll just leave it for now.

- What possible solutions exist? 1. Increase font size throughout the entire site. 2. Only increase font size in the menu. 3. Increase the spacing between menu items, and leave the font size the same. 4. On mobile, use a completely different menu layout, which has bigger links ; but keep the menu the same for larger devices

- What will the impact be? For solution 1 it will affect the layout of the entire site, cause some words overflow their sections on small devices, and possibly make the text less readable; but hopefully it will make the menu items more clickable (but probably not very well because size 11 text is almost as hard to click as size 10 when they’re stacked next to each other anyway).  For 2 just the menu might might have words which are now too big for their section, and areas next to the menu might l have layout issues, but everywhere else will be fine. For solution 3 there should be no words taking up more space because the text size is the same, but layout next to the menu might still be affected. And for solution 4 we will need to have co situ okay logic that determines the screen size, and design an entirely new menu layout and layouts for areas near the menu on mobile, but for desktop computers layout will be unaffected

- What prior art is there? The most common solution nowadays is the “hamburger menu” for small screen sizes, and regular menu for bigger ones.

- What experiences do I have that may influence my decision? For me, I don’t have a problem with zooming in my mobile device in order to click a button. It’s nice if I don’t need to, but I can live with it. But I know my parents would struggle with it. And the hamburger menu would probably confuse my parents, but everybody else I know is fine with it.

Ok so having considered all this, is increasing the font rise for the entire site the best thing to do? It seems to not be to me. It affects the most of the site and so causes the most work (certainly more than 3 hours), and I don’t think size 11 menu items will be much easier to click than size 10. So the original dominion doesn’t look like a good fit.
Now what about solution 2? It’s less work, but probably won’t fix the problem much better.
Solution 3 is certainly the easiest and is likely to fix the original problem. But it won’t be as smooth as solution 4. And it will make theme bu look a bit worse on big devices where the extra space isn’t needed.
Solution 4 will work great all around, but it might be more than 3 hours work to tell develop and test this more complicated work. Also it means we will have to always support two kinds of layouts. Also, having a hamburger menu might not be intuitive for older folks, but this site’s traffic is from a variety of age groups, so that’s not a huge issue.
So given the data considered, I think solution 3 is the best fit: it will solve the problem in the alloyed time, whereas option 4, although probably better and more common, seems difficult to execute in the given time frame. But seeing how you’ve given established the goal and timeframe, maybe once I step into the code, I see that solution 4 is feasible in the time frame too; so I can make that decision given the new information.

Who has time for planning like this?

But you think “who has time to do all that planning for some tiny task like that?” I have several items to mention:

1. I agree that it’s unreasonable to spend an hour planning a task that will only take 10 minutes to complete. However, I think taking 2 hours to plan a task that will take 10 hours to complete us much more reasonable. I think let’s keep the proportions similar here: I think a ten hour task merits about an hour of planning.

2. If you don’t have time to do all that planning, please assign someone to do it. Give them some direction, like your objective, how success will be measured, and a ballpark office much time and resources to put towards them. Share whatever information you already have, like what the problem is, a bit if your previous relevant experience, knowledge of prior art, what possible plans you already know about, and some guidance about where to look for assistance, and when to get feedback from you. Then let them take care of planning while you do whatever you think is more important. And yes I can do the planning of you need, but I need to know what the problem is, what your objective is, and a ballpark of how important this issue is. So just a few sentences, but certainly not just a command.

3. From my example, notice although the extra planning took a bit of time, it saved us from attempting the initial solution, which would have actually saved time.  And because it defined the objective of the change, we can know right away if it’s working; and because we defined how important the task is, we can know when we’re over budget.

Waterfall vs Agile

In the programming world, two main ideas of how to develop software exist: the waterfall development method, and agile development. Waterfall dictates that you first plan out absolutely everything, then develop exactly that, with no variance. Whereas agile is more iterative: you plan a tiny bit, develop a tiny bit, and try it out; after you’ve tried it out, you’ve learned that you’re original plan was probably wrong and so you start again. The idea being that your first plan won’t be very good, no matter how long you take, because you learn the most during development and testing, so get to those steps as quickly as you can.
So am I advocating the waterfall development method? Not exactly. I think I’m just advocating not skipping the short planning part of agile. If you haven’t established what the goal is and how you will evaluate success, when you develop and test it, how do you know if it’s any good? And if the task was into ally done with no way to judge its success, don’t be surprised that later on, when you introduce a way to measure success, that it’s not “successful”.
Well this is all my opinion, not backed up by references or studies, so I could be completely wrong. But worth chewing on anyway.
Even if you have considered, still good for me to know and see it. I can see opportunities while coding, and I will feel more accomplished.

What I like about my Work

https://cmljnelson.blog/2016/09/25/what-i-like-about-my-work/ September 25, 2016

4 minute read
My last post was kinda a complaint about how tasks have sometimes been assigned to me at work. (Of course at church, where I’m currently serving as “elders quorum president” I’m kinda in the position of assigning tasks, and frankly I kinda stink at it. I’m so conscientious that I might offend someone somehow that I really don’t do much of anything).
But overall I actually really enjoy my work, so I thought it would only be fair to mention that.
One thing I’m starting to learn in life is this: there is always something you can complain about, and there’s always something to celebrate too. You pick which to focus on. My LDS mission president, president Ricardo Castillo, said, in reference to how some missionaries seemed to have nothing but complaints about their companion, their area, and basically everything, “si ven problemas cosecharán problemas; si ven oportunidades, cosecharán oportunidades”, I’m English “if you see problems, you’ll reap problems; if you see opportunities, you’ll reap opportunities.” I believe that is true: if you’re spending all your time focused on things you don’t like, you become bitter and a problem yourself. Nobody wants to be around you. But if you see opportunities for improvement and focus on that, you’ll help things to improve, and this kind of cheery attitude is contagious, so others will like being around you. What’s more, I’m just realizing: problems ARE opportunities for things to improve. So a person who only sees “problems” might be looking at the same things as someone who sees “opportunities”: they’ve just each put a different label on it.
In case you don’t know, I work from home for Event Espresso, a distributed company making WordPress plugins (and I do a bit of work for my aunt-in-laws company, Pacific Rim early Childhood Institure, doing programming work, but mostly this post is focused on Eveht Espresso).
So what do I like about my job?

- I find the work interesting. We are usually building something new, which is very creative and exciting.  Both when I see it working, but also knowing things are well-organized behind the scenes. Sometimes I’m just fixing bugs but even those can interesting problems, kinda like detective work.

- I don’t have to do with cranky customers too much. Of course most customers are fine, but there are 1% who use up 50% of your time and 75% of your patience. I mostly get to stay out of that!

- I get to participate quite a bit in the design process, trying to design good user experiences. Knowing that what I’m building will actually be used, and trying to make it a good experience for them, is an interesting challenge.

- Seeing how I work from home, I get to be around my kids a lot. Sometimes it’s frustrating of course, having the 3 year old wanting to play, and the 7 month old typing random lines of code, but overall I’m really glad to be around them so much

- No commute. (Commutes are kinda nice because you can listen to audiobooks etc)

- My hours are really flexible. It’s nice for my coworkers if I’m on when they’re on, in case they have questions, but I do get to pick my hours

- My coworkers are all really friendly. Even though I’ve only actually met one in person, they’re all good about remembering birthdays, are all endorsing, and are really good at not taking things personally (it’s easy to have misunderstandings when most of your communication is just text)

- I also think it’s good collaborating with intelligent coworkers. It’s sometimes difficult coming to a decision, but I for one certainly learn a lot from them.

- I kinda enjoy participating in a global team (I have coworkers in Canada, USA, and England currently). What’s more, I often interact with WordPress folks from all over too. It’s neat participating in a global community

- I like working on open source software (most of what we do is technically free code too, meaning folks are free to use it, modify it, and even use it to make money; we really just charge for support and access to download it). As I’ve become aware of the free software “movement”, the more I find it strange having software on my computer or phone which I can’t inspect. That means the owners of the software could monitor all my acricuty and private data and never need to ask my permission, and it’s very hard for me to know they’re even doing it. So open source software seems morally better to me.

- The software I help develop and maintain is used by thousands of site administrators, who I’m turn have hundreds of users, so it’s quite possible that it’s used by millions of people. It’s really neat being part of something this big.

- Many of the web development skills I’m improving are directly applicable to my hobby websites which can have absolutely nothing to do with enemy registration.

- I get to work from my couch, bed, kitchen table, deck, big screen tv, or a regular desk.

- I get great snacks

- Oh and lastly they pay well (actually about double my salary from a local company where I did similar work, and that job was significantly better than other previous stuff.)

Anyways, it’s great. Highly recommend it to anyone to whom this sounds good. (And for the record, to my knowledge I’m the only person I know with a university degree related to computers that works with WordPress. Almost veryone else is basically self taughh)

Five Unspoken Rules of Contributing to Open Source Software

https://cmljnelson.blog/2017/10/04/five-unspoken-rules-of-contributing-to-open-source-software/ October 4, 2017

20 minute read
I made a lot of mistakes going from developing closed-source to open-source software, and want to share the unspoken rules I discovered in the process.
This post is intended for readers with programming experience (especially with WordPress), but who are new to contributing to open source projects.

My First Pull Request Disaster

Customizing BuddyPress Docs for a Client

Six years ago I was working at a company in Victoria BC Canada called The Number. We were creating a website for a government client who wanted to have a tool for its members to be able to share documents. The WordPress plugin BuddyPress seemed like a good fit because it would add the social network the client wanted, and the plugin BuddyPress Docs would allow the members to collaborate on documents.

Parliament Buildings, Victoria B.C. Canada. (Our client was probably somewhere in there)

The one feature BuddyPress Docs lacked was the ability to upload file attachments – by itself, it only supported shared documents like Google Docs, not sharing PDFs or spreadsheets or images. So we decided to customize BuddyPress Docs to add the feature our client wanted.
This illustrates a great strength of open-source software, including WordPress: it’s not only free, but it’s infinitely customizable.

So, I downloaded a copy of the plugin from the WordPress plugin repository, customzied it and found it worked fine. As an afterthought, I thought we’d “give back” to the community by submitting my changes to the master copy of the project.
The Pull Request Was Missing a Few Things…

BuddyPress Docs, like many WordPress plugins and themes, in addition to being on the WordPress plugin repository, is also hosted on GitHub. It turns out, GitHub is actually where most of the development happens, and the WordPress plugin repository is just where the finished product goes.This was the first time I’d ever attempted to create a pull request, and it took me a while to figure everything out. I thought I could somehow create a patch file, which contains all the changes, and upload it to the GitHubI created the pull request (a.k.a. patch) and sent it off. I thought the notes on the commits (a.k.a. changes) were self-explanatory, so I actually didn’t even bother giving a title to the pull request, or a description. It was the equivalent of dropping a digital baby off at the doorstep, ringing the doorbell, and running away.
So in order to get my code into the master copy of BuddyPress, I’d need to create a pull request. I’d never create a pull request before, and so it took a bit of getting used to. I incorrectly assumed I’d just use Git, the version control system GitHub is based on, to create a patch file that summarized my changes, and upload it somewhere on GitHub. I was wrong (it turns out, however, that’s basically what you do if submitting code to WordPress core on Trac). On GitHub, what you actually do is: fork the project on GitHub, thus creating your own copy of the project, then make the changes to that fork, and then use GitHub’s interface to request that the project maintainer pull the changes from your fork into their master copy (hence the term “pull request”, literally a “request to pull changes in”). Well, I was so engrossed in figured out that out, that I made a bunch of mistakes.
Because I saw my commit notes appeared in the pull request (that is, the labelled groups of changes), that there was no need to give a title to the pull request or any description. (Actually, I nameed the pull request “1.1.x”, what I thougth the plugin’s next version number would be). What I did was the equivalent online equivalent of dropping a baby off at the doorstep, ringing the doorbell, and running away.

My Pull Request Disaster

Boone was surprisingly grateful for the submission and said he’d take a look but raised some concerns about security and future maintenance. I’m not sure why, but I said absolutely nothing in reply. I totally ignored it. Maybe I thought he was ungrateful, that he should just accept my changes as-is. Maybe I thought “This adds a great feature. It works. Why don’t you just accept it?”
Here is 3-minute video that Boone and I created recently, dramatizing our earlier encounter:
Pull Request Post Mortem

My patch made no progress for months (because I didn’t understand the issues Boone pointed out, nor did I ask him to explain). Nearly a year later, Boone closed the pull request, saying he had basically added the same feature, but in a way that didn’t have the problems he had pointed out. He said my pull request gave him some ideas how to do it, but it was rejected.
Importantly, our client was left in a really bad situation. By customizing the plugin, if they ever updated their copy of the plugin, the customizations would be lost. That’s because when WordPress updates a plugin, it completely removes the old version of the plugin (in this case, the version that had my customizations) and replaces it with the new version from WordPress.org (which would NOT have my customizations). So essentially, they were stuck forever using the same version of BuddyPress Docs. That’s inconvenient if it gets other features added later, which they won’t be able to get; it’s disastrous if the security vulnerabilities are later discovered in it, and they are unable to update to fix them.

By customizing BuddyPress Docs, our client couldn’t update unless those customizations were accepted into the master copy.

Also, and I had grossly misunderstood that submitting code to an open source project used by thousands is much more involved than just making the changes to a private project seen by no one but yourself.
I didn’t realize it, but there were certain unspoken rules about contributing to open source software that I broke, which we’re going to dive into. In order to understand why they’re important than, it helps to realize how open and closed source software differ.
What’s The Big Difference?

Let’s Compare a Few Facts

There is a lot more to discuss and people with whom to discuss an open source project, as opposed to a one-off customization.

Writing code just for yourself is a bit like this…

…And writing open source code used by thousands is more like this.

Let’s compare the client’s website I was building to BuddyPress Docs, and just for giggles to WordPress, too.

Client Site

BuddyPress Docs

WordPress

Sites Using It

1

8,000

23% of 1,200,000,000 = 276,000,000

PHP versions supported

5.5.9

5.2.5-7.1.x

5.2.5-7.1.x

Compatible Plugins

about 10

52,000

52,000

Code Contributors

1

40

500

Hackers

A few?

A few more?

All of Them!!!

So the code I submitted worked fine on our customer’s server, using just their version of PHP, with the plugins they had active. But that in no way meant it would be ok on all 8,000 sites running BuddyPress Docs, on all the versions of PHP between 5.2.5 and 7.1,  with all 52,000+ other plugins on WordPress.org (not to mention unpublished plugins and customizations others may have made). Also, there were 40 other contributors who might want to discuss it, each with their own schedules, experience and styles, and mood-swings. And lastly, although a security bug on our client’s website would probably go unnoticed, it would be much more likely to be exploited if it became part of master copy (and hackers would be able to inspect the code themselves).
So when contributing code to open source, there is a lot more to consider and a lot more people with whom to discuss it.
And if you want to contribute code to a big project like WordPress, all those issues a multiplied exponentially.

Should You Take the Plunge into Open Source Software?

Am I saying you shouldn’t try to contribute to open source software? Yes; if you expect it to be as quick-n-dirty as building software in isolation. But I really hope you do venture out of your coding cocoon because there is a lot to be gained. Open source contributions are great for resume-building, you’ll support the software your livelihood depends on, and you’ll basically receive mentoring from world-class professionals you’d never get a chance to even interact with otherwise.
So I honestly believe it’s worth it, but there are a few rules I’ve learnd I’d like to share.

Rule 1: Justify Your Changes

When submitting your patch or creating a pull request, you need to show to the maintainer that it’s worth the costs. I thought my patch was a beautiful hand-made masterpiece, like a piece of hand-knitted clothing, but it was actually an ugly sweater you not only don’t want to be seen in, but it may have lice and other bugs.

I thought my patch was this…

[Image removed]

…but it more like this…

[Image removed]

…and may have contained this.

And even if you just store your sweater in your cupboard, the bugs may creep from it into everything else you wear. (I think the analogy to software bugs is obvious here)
Pitfalls of Patches

Project maintainers need to be very careful about what changes they accept from strangers. When deciding whether to accept your patch, they need to consider:

- does it add any vulnerabilities? (could users get hacked because of this?)

- does it add any other bugs?

- is it compatible with all the supported versions of PHP, and MySQL, and web servers, etc?

- will it conflict with other plugins and customizations?

- does it fit into their feature roadmap? (and, usually, it will make adding other new features harder)

- how will it affect performance?

- will most users use it?

- will most users like it?

- is it worth the extra work to maintain it? (because all that code may need to be rewritten the next time-related software is updated)

Although Boone appreciated my contribution, it wasn’t so much of a gift as an obligation: the obligation to evaluate it, and if accepted, the obligation to forevermore maintain it himself. Someone on twitter once said “All code is technical debt”, meaning even clean, well-written code will require work to maintain. So every code contribution adds to their workload.

[Image removed]

All new code added to a project adds to the maintainer’s workload

An Improved Pull Request

So if you want your pull request to be accepted, the project maintainer needs to be convinced it’s worth the risk. These are things to mention:

- describe the feature (a high-level overview, they can look at the code for details)

- your use-case (why you find it useful for your project)

- other use-cases (other applications you’ve heard of or can think of)

- prior art (other projects with similar features and why it’s been good for them)

- why this implementation (why not do it another way)

What justification did I give to Boone that my feature should be accepted? Absolutely none. Did I at least tell him why I did it for my own project? Nope. Did I convince him the benefits of this feature outweighed the potential maintenance costs, bugs, and vulnerabilities? Absolutely not.
If I were to do it again, I would have added a title and description, something like this:

[Image removed]

How I should have described my patch

Rule 2: Be Willing to Discuss and Revise

My Pull Request’s Discussion

Even though I gave no justification for why the feature was worth it,  Boone still followed-up with a bit of a discussion about it. To which I made absolutely no reply.

[Image removed]

This was my reply to Boone’s questions… “crickets”.

I should have realized that, of course, he’d have questions about it. If he accepted it, he was the one who was going to maintain it, answer questions about bugs it might have, and apologize to users if it introduced a security hole that made their sites get hacked. Not me, I was probably going to disappear. He needed to firmly know there was no problems with it; all his questions needed to be satisfied.
There are a million aspects to consider, and it’s unlikely my first-attempt would have satisfied them all (actually, it’s unlikely until it’s released and people start using it). Even regular contributors’ code contributions often require a lot of discussion and revisions.
What Does Silence Mean?

What did I, or anyone, communicate with silence?

- “Uh- could you repeat that? I wasn’t listening”

- “I understand so little of what you just said, I don’t know what to even ask. Please explain more.”

- Nobody’s here. Try again later, or try somewhere else.

- “I’m thinking or checking with others, please wait”

- “I thought someone else would reply”

- “I’m too busy right now”

- “I’m really tired of this and want it to just end”

When someone doesn’t reply to us (be it over text message or pull request discussion), we damage our own well-being by usually assuming one of the latter reasons; and yet often when we don’t reply it’s because of one of the former reasons. Everyone’s happier when you assume the best and try to give replies, even if it’s “I don’t understand” or “Please wait”.

A More Typical Patch’s Discussion

I’ve been following a WordPress core ticket 38645, done by one of the biggest (and most memorable) names in WordPress, John James Jacoby. John explained the changes’ purpose and provided the code. Everyone agreed they were beneficial changes, and he’s submitting code to WordPress for over a decade. Despite that, there would be 7 revisions, 32 comments, and 11 months before it was accepted. Many newbs get cranky if their patch takes a week to be accepted.

[Image removed]

WordPress Trac issue 38645, written by a WordPress veteran, took 7 revisions, 32 comments, and 11 months to be accepted.

Lastly, if it’s your first time contributing code to a project, it’s likely you overlooked some aspect of the project’s standards for code or contributing. WordPress core has coding standards, but most projects have different ones.
Overall, getting a code contribution accepted without any discussion is very unusual. Expect there to be discussion and multiple revisions before your code is accepted.
Where The Real Learning Happens

This may sound a little discouraging, you would have probably preferred to hear “contributing code to someone else’s project is easy, and there’s never any need to discuss or revise anything.” But there’s a big up-side to all this: it’s where the mentoring by “world-class professionals” happens.
“Did you think about using x?” “What about users with y?” “If you do it like that, it’s a security vulnerability of type z.” I’ve found that it’s during discussing open source software that I learn a ton that helps me to be a better developer.
I could write an entire blog post on how to communicate effectively about open source software, but I’d like to just mention two tips.

Seek first to understand, then to be understood
-Stephe R. Covey

This is especially important in online, technical discussions. Re-read what others post at least twice, research everything term they mention, and try your best to understand the facts and why their priorities. What’s more, it’s often in the process of understanding the other person’s argument that you’ll either see its merits, or help them see its weaknesses. In honestly trying to understand others’ arguments you’ll build a better relationship, and lead to a quicker resolution.
When it comes time to be understood, try to make your comments not-to-long but not-to-short (don’t give a rant but do explain your argument well). Your argument is incomplete if you don’t provide an example, or a video, screenshot, or code sample. Provide links to pages that give further information.

If you can’t explain it simply, you don’t understand it well enough.
-“Albert Einstein” (supposedly)

What if you already understand the other person’s argument “perfectly”, and the problem is just that they don’t understand your argument? Chances are you don’t understand it well enough, otherwise you’d be able to explain it well enough that they would understand. In takes a great mastery of a subject in order to explain it simply. So even if you think you already know everything, just trying to explain it better and more simply will actually help you to master the subject even more.
(And generally, even if you have the most experience or authority on the subject being discussed, I still think it’s best to explain your reasoning or experience, rather than just say “this is better because I say so.” You may be right, but no one else will learn from your expertise unless you share it… only communicating decisions without any of the rationale is obviously faster in the short-term, but the long-term consequence is the learning is stiffled.)

An Improved Pull Request Discussion

If I were to have done my patch all over again, it would have looked more like this:

[Image removed]

How I wish I had responded to Boone’s questions on my pull request

Rule 3: Be Positive and Grateful

The Value of Keeping It Positive

It doesn’t hurt to get on project maintainer’s good side. I now help develop and maintain Event Espresso,  another WordPress plugin, and we get sometimes issues or pull requests from people who are just seething venom. We still try to act objectively and consider the merits of what they’re saying (not the way they said it), but it’s hard to think straight when you feel offended.

To have happy and healthy open source communities, we need to learn how to be smart about our emotions…
[Y]our community is made [of] humans not laptops. So assume good faith or better, and always communicate in a friendly way regardless of what your current emotions are…

from https://opensource.com/article/16/11/communities-emotions-matter
When you’re having a discussion about someone else’s project, whether it be part of your pull request or just an issue, realize that you’re a digital guest. You are standing on someone else’s “property”, and should behave yourself, or else you’re liable to be kicked off. If you’re behaving like a troll (someone who just wanders around the internet stirring up trouble), you will be treated as such and be kicked out.

[Image removed]
Chris Lema compares some comments to spraypainting on his house.

Chris Lema, a frequent WordCamp keynote speaker, has a similar policy regarding blog comments, which I think translates equally well to comments and discussions on open source projects

[You] can’t go to the outside of my house and spray-paint on my walls.
When you come into my house on the web, you can read all my posts, and you can write any comments. ..but you don’t get to decide whether I keep your comment and I make it public. I’m ruthless about taking down your trolling comments and getting rid of them on my site.

see https://austinlchurch.com/how-to-become-a-blogger-tips-on-starting-a-blog-from-chris-lema/
So when you’re a guest of someone else’s open-source project, realize you are entitled to nothing. You don’t get to demand things, or make them feel bad. If you do, you’ll quickly get the cold shoulder, or get shut out outright.

WordPress “Big Names” Always Keep It Positive

What’s more, having a bad attitude and acting entitled not only labels you as a jerk (and people avoid jerks) but also as a newb to the WordPress community.
If you watch the tweets between the WordPress big names, they’re always encouraging, thanking, and sometimes downright praising each other.
These tweets are very typical for WordPress big names:

[Image removed]

[Image removed]

[Image removed]

[Image removed]

[Image removed]

It’s only the nobodies who are criticizing. (In truth, the WordPress big names sometimes criticize, but that’s more the exception than the rule.)
My patch for BuddyPress Docs wasn’t exactly negative -I really didn’t say anything- but it wasn’t positive, either. I never thanked Boone for the software he provided and maintained for free, nor did I thank him for his initial look at the code, nor did I thank him for his follow-up (although I did, only recently, do that on Slack).
Show Your Gratitude for Free Software

What’s more, if I wasn’t putting my “money where my mouth was”, I should at very least have put my “stars where my mouth was”. I mean, I should have given it a positive review on the WordPress.org plugin repository. We depend on free software for our livelihoods, and yet most don’t give a penny towards it, nor even a positive review online.

[Image removed]

I finally left BuddyPress Docs a positive review online

In the process of writing this, I finally rectified that mistake and gave a 5-star review for BuddyPress Docs. I now generally make that a habit for all plugins or themes I use (and apps, programs, and even restaurants I like). I’m invested in them and want them to succeed, it’s in my best interest to give them a positive review.
So far I think it’s helped too. When I try to stay positive and grateful for any help I get from project maintainers, it’s not only a good experience for me, where I often get what I was wanting, but I think I make a much better impression. Seriously, it seems only newbs are jerks.
Rule 4: Small Changes Are Easier

Less Code Means Less Discussion

[Image removed]

Smaller patches are easier to fit into projects than big ones.

The two previous rules pointed out there’s a lot to consider before and after a patch is submitted. This rule is a way to avoid a bit of that. If the change you propose is small, it will be easier to accept. While maintaining our plugin Event Espresso, we accept changes that fix a typo, add a missing closing HTML tag, or add a WordPress filter much more easily than we accept changes to how taxes are calculated.

Not all maintainers are keen on accepting massive change sets from new contributors.

from https://opensource.com/life/15/2/developers-guide-getting-involved-open-source
The feature I was adding to BuddyPress docs was quite significant and so was unlikely to be exactly in-line with Boone’s vision for the project, and required a good deal of analysis.

[Image removed]
Keep your patches slim!

So what can you do to keep your patches small?

- If your patch changes more than a few dozen lines of code, STOP! Check with the project’s maintainer if what you’re adding is what they want

- Make separate patches for distinct features/bugfixes (don’t put all your eggs in one basket, or your changes in one pull request, so that each one can progress unincumbered by the others)

- focus the patch’s purpose and avoid unnecessary improvements (e.g., if you’re fixing a bug, don’t try to squeeze in a new feature with it, or go fixing variable names in other parts of the code- do that on a separate patch)

- Don’t Repeat Yourself (if you are copying and pasting code more than once in different parts of the project, you’re repeating yourself; make a function or class that does that and reuse it)

How to Achieve Big Features with Small Patches

But how could I have made my change smaller while keeping all its features? I could have created a patch that only added a few WordPress actions and filters, and then put all my code in a new plugin that hooks into those actions or filters.
For example, in my patch, I added a bunch of HTML to show the form for handling the attachment uploads. The exact content of the code doesn’t so much matter, as just noticing its size. Here a portion of my patch:

[Image removed]

A snippet from my original patch, which added HTML for the file attachments form

There was quite a bit of HTML being added. Instead of putting all that in my patch, I could have simply added a call to do an action, like so:

[Image removed]

A much, much smaller change than my original patch

If you were the project’s maintainer, which would you more easily accept? My original big change, or the tiny one-liner that actually doesn’t change anything (unless it’s hooked into). So what about my HTML? That needs to go somewhere. So we’d put it in all in a separate plugin, like so:

[Image removed]

A sample snippet that could be placed in a separate plugin

Again please note, that this last code snippet would only appear in my own plugin; so Boone would never even need to see it or consider it.
Had I created my patch like this, Boone would have needed to only review the added actions (which, if not hooked into, do nothing), which would have made accepting my changes dead easy. Plus, the same feature still gets implemented.
Rule 5: Companion Software is the Easiest

It’s possible to avoid all discussion with a project maintainer entirely, if, instead of creating a patch to add a feature to someone else’s project, you create your own project that extends their project. In WordPress, that usually means: instead of creating a patch to add a feature to WordPress core or one of its existing plugins, create your own plugin that adds the feature.

[Image removed]

Batman can’t be everywhere at once, he needs Robin to help. Likewise, most software projects need companion software because it’s impractical for them to support every feature under the sun.

The Benefits of Companion Software over Creating a Patch

E.g., instead of trying to add file uploads to BuddyPress Docs, I could have created my own plugin that did it. This way, Boone would have had a lot less, if anything to worry about.

- Because no changes were made to BuddyPress Docs, it couldn’t introduce any security vulnerabilities or bugs, or slow it down, or add to Boone’s maintenance burden

- If I put the plugin on WordPress’ plugins repository,  it would only be used by folks who wanted it; everyone else wouldn’t be bothered with it

- If my plugin became sufficiently popular, then Boone could consider merging that functionality into BuddyPress Docs. At this point, the feature’s value would have been demonstrated

And guess what happens once you’ve created companion software and made it available online? You’re now an open source project maintainer! Welcome to the club!

WordPress’ Companion Software Policies

That’s actually WordPress’ policy anyway: with few exceptions, all new features for WordPress core actually begin as “feature plugins”. Then, if they are sufficiently popular and useful, they will be merged in. That was how the WP REST API was developed and eventually merged into core; and how the new WordPress editor, Gutenberg, is being developed currently.
Another policy of WordPress is the “80% principle“:

The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it.

That is a common principle for most open source projects. Would 80% of BuddyPress Docs users want my proposed feature? I’m not sure, so it certainly would have been better as a separate plugin initially.

Separate Code is Faster Code

[Image removed]

By writing a separate plugin, you are free to develop it independently of the software it extends.

One last advantage of making a separate plugin is that it can be developed faster, and independently, from the project it extends. Why is that? Because if my plugin is used by myself, and maybe a few dozen other users, then making a change affects a much smaller group, and has less related software it needs to operate with (e.g., each server it’s on may be using a different version fo PHP, MySQL, web server, WordPress version, plugins, etc). Whereas if my changes become part of the main plugin, used by many more sites, each new change needs much more consideration and testing.

[Image removed]

Recently someone created an add-on for Event Espresso, instead of submitting the code directly to us. The user aparna249 created Files Add-on for Event Espresso 4, which allows registrants to upload files while registering for events. They didn’t need to discuss the changes with us, we don’t have to maintain it, and they don’t need to worry about losing their customizations when Event Espresso is updated on their server.
And once you’ve created a plugin or other open source project, and make the code public, guess what you will be? A project maintainer. One of us.

[Image removed]

Conclusion

Summary

Contributing to open source software will stretch you at first. But that stretching will not only mean better software, but you will become a better developer.

[Image removed]

People who contribute to open source software

Just remember the five rules I mentioned:

1. Justify your Changes

2. Be Willing to Discuss and Revise

3. Be Gracious and Positive

4. Small Changes are Easier

5. Companion Software is the Easiest

How to Fulfill Your Destiny

[Image removed]

So what should you do now? Here’s a checklist:

- use open source software (like WordPress) and give it positive rating (assuming you want it to stay around)

- when you notice a deficiency, suggest an improvement (for most WordPress plugins and themes that’s on the WordPress.org plugin and theme repositories, but also often on Github, and for WordPress core its on trac.wordpress.org)

- become familiar with using the version control system Git and making a pull request on GitHub

- open a pull request to fix a bug or add a small feature for a project you use

- create companion software (e.g., make a WordPress plugin) to add more significant features to software you already use, and publish it on GitHub

- participate in a project’s discussion (for WordPress, this is on trac.wordpress.org and in the weekly dev chats held Wednesdays)

If you have experience working with open source, you have probably discovered other hidden rules that I missed. Please tell me in the comments!

WordCamp Seattle 2017 Memory Dump

https://cmljnelson.blog/2017/11/04/wordcamp-seattle-2017-thoughts/ November 4, 2017

17 minute read
This last weekend I attended WordCamp Seattle and learned a ton. I mean a ton. This post about it is really long! Just read the headings you find interesting.

The Journey

Getting to the WordCamp was a bit of a pain though- the weather was not favourable. First there was a surprise snow-storm in Shawnigan the night before my flight, which looked like it was going to make the drive to the airport impossible. I was wondering what they’d do if I couldn’t make it to my presentation… Morning of my flight, though, the snow was cleared.
But then the blizzard that passed over us was now over Seattle. So my flight got delayed one hour, two hours… it got delayed 5 times, leaving 5 hours later than scheduled. I barely made it to the last 20 minutes of the speaker’s reception.
But made it I did. Admittedly, arriving at the very end of it was a bit awkward, everyone was already well-engaged and chatting it up. But Larry Swanson came over and made me feel more at home. Also met Steve Case who was really friendly. Met Devon Delapp in-person (we had just chatted the night before, practicing each of our presentations on each other, because we were guaranteed to miss each others’ because they were at the same time) and he was also really friendly. He promised to come pick me up for the next WordCamp in his club’s plane. Promised! (jk)
My hotel, the Baroness, was a blast from the past. I suppose it was cool staying in the same type of accomodations my grandparents would have enjoyed. But the wifi worked so I got a bit of work done, the room was quiet, and I slept like a log.
I managed to arrive at WordCamp in good time. I managed to go in the wrong line twice (first because I forgot my alphabet, then because I forgot I was a speaker). So that was an amusing start.

WordPress is a Banquet

Andrea Middleton’s keynote presentation was informative. I thought hearing the stories of WordPress contributors was helpful, and she had an excellent point that, especially with WordPress, you don’t need to know any code to contribute. (That assertion might not be as true for some node.js libraries etc and other projects only known and used directly by developers, but WordPress is at the stage where it needs a lot more work than code).

Using Open Source Code As Your Resume

While waiting for the first presentation to start, I spotted a guy who similarly was just waiting around alone so I said “mind if I introduce myself? I’m Mike. What’s your name and what brings you here?” His name was Aaron Sturm, a developer. He told me how he’s currently making a Tribe Events Calendar integration with Slack, and that he’s hoping to make to share the code on GitHub, which I strongly supported primarily for his own benefit: for learning and notoriety. We talked about how writing an integration like that is a great signal to that company (and others) that you got the skills– probably more so than anything you put on your resume. Most of Event Espresso’s hires (strangely, excluding myself) landed the job because they helped report issues to us (Tony Warwick), built sites with it (Brent Christensen) or built other plugins we used (Darren Ethier).

Dynamic Scaffolding using the WP-CLI

Ben Byrne’s presentation on how they’re using the WP-CLI I for dynamic scaffolding was great: for web devs, creating WP-CLI commands for speeding up oft-repeated site-setup tasks makes a lot of sense (like restyling the login page). Relying on a premium theme to do stuff does often stink because they try to do so much, and you invariably need to tell clients “oh, just don’t touch those settings (they’ll break the site, or confuse you)”. Plugins for each of those is nice, but I can see how it’s nice keeping those away from the client’s access if they’re just going to break things or be confused by them. I can see how it would be great to make a WP-CLI command for generating Event Espresso add-ons. I’m pretty sure my coworker Darren previously suggested that…

Why is Microsoft Using WordPress?

While getting myself seated for the next presentation, I once again introduced myself to someone with my very original “Hi there, mind if I introduce myself? I’m Mike. What’s your name? What brings you here?” This time I met Casey from Microsoft with whom I had a great chat too. It surprises me to no end that Microsoft utilizes WordPress- the worlds largest software giant uses free software made by mostly-non-degree holders mostly volunteering from their homes in their pyjamas.
I asked him “doesn’t Microsoft have the means to build their own blogging software?” I’m sorry I don’t remember exactly how he responded, but basically they think it’s best to use WordPress. Why reinvent the wheel? and a large organization like that can move really slowly (that was my experience at BYU office of IT which had about 100 engineers; and it’s why my brothers small company doing FileMaker Pro does work for big banks).
So does Microsoft support the development of WordPress? Not directly. They hire 10up to meet their WordPress needs, and 10up contributes a ton.
Just last week I was working with 10up’ers on WordPress core- from my couch, I was working with Microsoft’s hired experts. Weird.
Also weird was that a Microsoft employee was at an event costing $20 per day, also attended by small site owners.

“Death of the Media Query” and Cool CSS

Saied Abbasi’s presentation on the Death of the Media Query. Was great for becoming familiar with some of the more-recent CSS tools for making responsive websites, and making it really easy. Things to google: caniuse.com, and the following CSS terms calc, vh, between, flex, grid, justify-content, fr, repeat , grid-auto-flow, and @support. I also enjoyed the tree of serenity (slide he posted for a second between tons of code to help us “clear our minds” or something. It was amusing at very least. And although it was quite a lot of code, it was much easier to learn like that than from a textbook).

Between session, I visited a few of the sponsors tables, grabbing swag (mostly stickers for my girls). While they were certainly there to promote their product, I appreciate that they also acted like members of the community, not opportunists trying to swipe everything they can and run.
Among the sponsors that I talked with was Avalara. I can see how their tax calculation service is great for small sites where keeping track of all the world’s tax calculation rules is simply not pracical. It would be nice to get that working with Event Espresso.
Event Espresso did not sponsor this WordCamp (but have others). It’s hard to quite put your finger down on the benefits, and certainly had to weigh them against a fixed price tag. I found a really good article discussing it on WPTavern. I appreciated how realistic it was. Looking purely at new customers acquired as a direct result of sponsoring a WordCamp painted a very dismal picture of it.
I did feel a sense of loyalty to the sponsors though (which is hard to measure, of course). E.g., just because BlueHost was there with a banner, giving a away a few t-shirts, I feel more loyal to them. I have their dirt-cheap hosting for my hobby family history site, and previously planned to jump ship the moment they tried to raise the price. Now my default is to stay with them.
And not only did their sponsoring WordCamp make me more aware of their brand, the fact that they’ve essentially paid for my ticket to attend WordCamp, helps me to view them more as community members, and less as self-interested companies trying to get all the profits they can (both are probably true to an extent, but in that moment I see more of the former). But are these benefits worth the price tag? I have no idea.
But thanks BoldGrid, Automattic, Bluehost, DreamHost, GoDaddy, SiteLock, Pantheon, Pressable, Avalara, plesk, 10up, WPML, IvyCat, SiteGround, Lexblog, and GreenGeeks. I appreciate you making my WordCamp experience possible!

Mental Health in the Developer Community

Ed Finkler’s presentation on Mental Illness in developer communities was important. It was pretty poorly attended, which may have just been an awkward scheduling conflict (the Javascript workshop was going on at the same time, which admitedly I probably would have gone to instead if I weren’t also presenting during the second hour of). But I’m guessing it also makes the point of what he was saying: we treat our community like a community of laptops, not people, always focusing on the tech. And while we all like making software and being successful, those are actually only means-to-an-end. We want to be happy, and have others be happy. Being happy without being successful is still happiness. Being successful without being happy is still unhappiness. I think that’s the point he’s making and think it’s a good cause.

Panacea for Invoicing and Supporting Clients

I didn’t get to attend Devon Delapp’s presentation on how they built a great tool for a service-based business, but I did practice with him earlier, during which we each saw each other’s presentations. I can see how the service tool they’ve put together, Maintaingo, would be FANTASTIC for web agencies charging clients per-hour for web services etc. I remember at thenumber.biz that invoicing was a huge headache: tracking hours billed and getting paid. He said they did white labeling, could help folks set up the whole system, but I was saying it would be great if they totally open-sourced their code. (I’m sure people would see how much work it was to set up, and probably hire them instead.)

Intercepting BobWP

Before my presentation, I bumped into Bob Dunnand said “Hey Bob WP!” I don’t really recall how our conversation went after that, but it was surprisingly natural. He had no problem conversing with a fan on twitter (although to be honest, I never make time to listen to podcasts, including his, because I don’t commute and I can’t listen to that while get work done… I’m much more of a eclectic blog reader). Eventually I told him I was going to present and show a video, and he started to tell me about horror stories of when he made presentations and all the AV stuff was a mess. But he assured me that wouldn’t happen to me. He said he also has some thoughts of making filmed, edited videos (not just video podcasts) as he has a script of sorts written out, but he doesn’t consider himself the flamboyant excitable type to do that, saying it would be unnatural to him.
I similarly am not a really exciting person, I think. Pretty calm mostly. (Amanda has all the joie-de-vivre). But others feel like that and don’t have to change that to become successful (I don’t know how successful he is, but having 13,000 followers on twitter counts for something).

Sweaty Palms and My Presentation

It turned out hooking everything up for my presentation went perfectly fine, including connecting the audio and everything. No problem. Phew!
My crowd was more meagre than I expected (I’d guess probably 30 in attendance, whereas I was more anticipating 100+) probably because it was at the same time as the much-anticipated “Women in WordPress” forum (which I would have attended too instead of mine, to be honest.)
I made my presentation a little bit interactive by asking the audience to discuss a few items with their neighbour for 30 seeconds at various points in the presentation. My idea was that it would help wake them up if they were getting bored, help them process the information a bit better, and be a kick-starter for a bit more networking between them. I think it went it worked as most people were quite happily chatting away (some of the back row, on the other hand, sat silently. I kinda get that, sometimes if I start off an event like this on the wrong foot, without knowing anyone and somehow I don’t shift into “temporary extrovert mode” I kinda get stuck by myself too. Or maybe they just had a server crash or something and so were busy on their laptops. Anyways, I think the participation thing didn’t really work for every single person.)
The group liked the video, I think. They laughed at Boone’s ad-libbed part about “How do these people keep finding my house?” and clapped at the end. I’ll talk about the video more in a second.
If I did my presentation again, I would have made it more accessible to non-developers. Even though I geared it for developers, it appeared to me about half of my audience weren’t that type (I asked for a show of hands, and about a quarter weren’t familiar with GitHub, and three quarters were unfamiliar with WordPress Trac).
Overall, would I present again? Definetely. It helped me a lot to develop my understanding of the material, preparing and presenting were also good experiences, and it helped me get a lot more involved (I got to connect more with the organizers and other presenters).
Was it worth the opportunity cost? I think so. Time spent making and tweaking the blog post, then making and practicing the slides was probably around 12 hours total, which I could have spent working. But really, I think it helped me professionally much more than 12 hours working. I enjoyed it and it gave me a much better sense of accomplishment and giving back to the community.

You Can’t Just Open a Pull Request and Run

Before you watch the video, please be aware: a “pull request” is a request for someone to accept changes to their software. Ok, now if you haven’t seen the video already, go ahead and watch it.

So the morale of the story is hopefully prety clear: if you’re contributing code to someone else’s project, you shouldn’t just drop off your code and never be heard from again.
A few notes about making that video: like it said, it’s inspired by my first pull request. The project maintainer who received the pull request was actually Boone Gorges, who acted in the video. Which is weird or cool.
I contacted him a month or two ago on wordpress.slack.com, told him I was preparing this presentation and had this weird idea to make this video, and wanted to see if he’d be interested in participating. Without much hesitation he jumped in with “I’m in! Send me the script!”. (I’m not sure which was stranger: my idea, or the fact he bought into it so easily! That seems to be the WordPress culture though. Just a bunch of really chill people.)
So I drew up a storyboard (I’ve watched special features to films, it’s what they do) and Boone digged it. Now, we literally live on opposite sides of the continent so we’d never film together, and so we had to use tricky camera angles to deceive the viewer into thinking we were actually both present.
When you see “Boone” open the door, it’s actually me opening my door, just dressed like him; when you see his sleeve as he clicks on the mouse it’s me again (notice it’s actually a completely different laptop, and actually his laptop has no mouse!); and when you see his sleeve gripping my collar, it’s actually my arm yet again! When Boone appears to have tackled me, and is threatening me with the USB stick, he’s just grabbing a pile of clothes. …It was a lot of fun putting that together.
And how did I piece it all together? Just used iMovie from my phone. It was kinda brutal doing video editing from the tiny screen, but it otherwise worked great and was pretty intuitive. I snagged most of the music from Street Fighter 2 MIDI tracks. (Converting from MIDI to a format playable by iMovie was impossible. Supposedly iMovie supports MIDI but it just gave me errors. Also, I really didn’t want to pay for a program to do convert it; nor did I want a free program that would install spyware or the Ask Jeeves toolbar onto my browser. So what did I resort to? I played the music from my laptop’s speakers and used my phone’s microphone to record it. It’s not Hollywood, that’s for sure.)

Cornering Felix Arntz

I spotted Felix Artnz, recognized his avatar from WordPress Trac, knew he was quite involved in WordPress core, so ran him down. I asked him why he contributes to WordPress, because it’s something I’ve wondered about a lot. He said he mostly just likes the sense of community, and usually commits 3-5 hours a week. He’s currently a digital nomad, touring around the USA and will then return to his native Germany, so I can see how community is actually quite a nice benefit for him. (I’m not sure if that’s usually such an important feature for people who are satisfied with their current sense of community?)
We discussed getting started with contributing to WordPress. We agreed there are quite a lot of resources on “how-to” do things like setup a dev environment, submit patches, what the coding standards are. But there’s a lot of social rules which aren’t as well-defined. That was basically the topic of my presentation. And he’s also planning on talking about something similar during WordCamp USA.

Managing Big WordPress Sites

Next I attended the forum discussion on managing big WordPress sites, by folks from Seattle Times, Disney and Microsoft.
It was interesting hearing about what they do and how it doesn’t differ from what we do for eventsmart very much.
When it comes time to update WordPress core, plugins, etc, they just do that all on a staging site and the test it for a week. Some of them have automated tests, but mostly it’s manual.
They said they do try to keep the number of plugins down, which helps reduce the amount of testing required.
They use elastic search for managing the HUGE data sets they have.
None of them use a site builder, nor will they be moving to Gutenberg anytime soon (they have way too much integration done with TinyMCE).
How do they educate their content creators? They’re tired of writing documentation. They suggest you just make a screenshare of how to use it, and provide a playground for them to try it all out.

What WordPress is Doing to Keep Your Site Safe

Aaron Campbell’s presentation on what WordPress is doing to keep your site and it’s users safe was nice too. It was not super well attended either, which was surprising considering he’s basically one of the most important security experts in the world, being the WordPress security lead developer and all.
It was interesting that he thought the prime directive of WordPress security is balance: between usability and security. Which surprised me, because usually security buffs have an attitude of “you can never make things too secure (no matter how unusable and complex things become)”. His perspective on security was surprisingly grounded in reality instead of hypthetical “what-ifs” and near-conspiracy theories that I usually associate with security discussions.
He did firmly believe everyone should be auto-updating though. Citing that it has a near-perfect success rate, the likelihood of it introducing bugs is low because it’s a security-only update, and besides, having things busted I’d probably better than getting hacked.
On the other hand, he thought the practice of moving the WordPress log-in page was futile. Hackers can not only easily find it (they just go to the admin and will be redirected to the log-in page) but there’s better ways for them to attack anyway (like using XML-RPC).
Aaron mentioned that 90% of the vulnerability reports for WordPress core and its related sites (like WordPress.org, the wordcamp sites, etc) are actually invalid. I later asked why that is. It’s because lots of the reports are basically automated vulnerability checkers that don’t understand how WordPress works (eg sometimes they report it as a bug that the site admin can create a post with javascript in it, ignoring the fact that site admins are meant to be able to do anything, as it’s their site).
I also asked Aaron why there are so many “bad actors” out there, why not make their living more honestly. It might because of the rush they get trying to hack a site (he said that in his young, more foolish years, he may have been one of those), or it might be that there’s actually big money in it. For example, apparently bad guys will pay $100,000 if you can tell them about a remote-code execution bug in WordPress core. So the rewards for HackerOne.com bug reports (usually over $350) is pretty minor, in comparison. He said they aren’t going to attempt to get into a bidding war with bad guys for vulnerability reports, as they will never be able to afford that. It’s really a way of saying “thanks for doing the right thing”.

After Party with WordPress Security Big Whigs

That was the last presentation I could attend, as I was headed back home that night. I kinda wanted to see if I could say hi to Weston Rutter, and maybe ask him why he decided to be the release lead for WordPress 4.9 etc, but him and Felix were pretty intense into some technical discussion I didn’t want to interrupt.
So I wasn’t sure if I wanted to go to the after-party to be honest, just the speaker reception was loud enough, and this was going to be even louder, it seemed. But some girl was asking if anyone knew how to get to the venue, which I did, so I offered to show her. Some other guy tagged along too.
I’m afraid I forgot the girl’s name, but she was really friendly and going places. It turned out the other guy was Mark Maunder, CEO of WordFence.
When we arrived at the after-party, Mark met up with Aaron Campbell and they decided to get a separate table because it was really crowded and noisy in the WordCamp’s reserved area. Aaron asked if he wanted anyone else to join, and Mark was just like “Uh not really, besides these two people I walked over with.” (Suddenly because I had walked over with him for 2 minutes from the conference to the after-party, he was now including me as one of his buddies!)
So I joined Aaron Campbell and Mark Maunder for dinner. That was unexpected. Plus Mark just decided to cover our meal and that of 3 other guys (who all had name tags so I learned their names: Andrew Villeneuve, Andrew Wood , and Ian Dunn). I can see someone doing that if they’re wanting to schmooze with big names etc, and maybe the other guys there were. But really not me! I was just impressed that he was so friendly to nobodys like me as he was to WP community big names.
They had a really interesting conversation, to which I mostly just listened in. They talked a lot about DefCon, and the “hacker” community. It sounds like a much different vibe than WordPress! Mark said how often they had their meetups in clubs with (my words) yucky feeling atmospheres.
Andrew Villeneuve mentioned that he met and interviewed the guy Catch Me If You Can is based off of, Frank Abagnale. Among other things, Abagnale suggests that you don’t just use a diamond paper shredder, because there are tools to reassemble paper shredded that way, but instead suggests you use a micro shredder, which will turn the paper basically into dust. LOL.
They thought the people who are really good at security might have difficulty relating to us “lesser humans”, and they are sometime the middlemen between those tech wizards and the rest of us. Sometimes even though a particular techy as clearly more security-savvy than others, others might not want to work with them because they’re just hard to get along with. Mark pointed out a one point that because of Aaron’s ability to diffuse heated discussions, it seemed instead of being the WordPress security lead developer, he would be equally good as a delegate for the United Nations.
Mark told a bit about how his company often works with law enforcement, which was also a little too “real-world” for me. I’m accustomed to “online” basically equating to “pretend”. (My parents generation says “go make some REAL friends, don’t just chat with people online”, and I think my parents sometimes forget I work at all). And yet here is a plugin owner telling how they needed to explain about attacks coming from someone in their jurisdiction and that they needed to be apprehended.
Previously, I had listened to a Great Course about Cyber Security (I highly recommend everything on their website, but I’d go with their monthly video service, “The Great Courses Plus”, as it seems more affordable to me). It was really interesting hearing about hacktivists facing off with drug lords, StuxNet and cyber warfare, and it gave me all sorts of ideas for an amusing short story (I’m not a writer). One about a programmer like me getting caught remotely caught up in online money laundering, drug cartels employing hackers to plant logic bombs to ignite hot water tanks and crash cars, and even nuclear metldowns etc. I thought there was some amusing material… all happening without the characters ever needing to meet face-to-face. But talking with these guys made me realize that wasn’t just an amusing premise, it’s actually a bit too close to reality for comfort.
Imagine if a hacker does manage to expose (or plant) a bug in WordPress core, which allows them to turn 23% of the web into their botnet to be used for attacking governments and infrastructure. That’s pretty powerful stuff.
Later, somehow the topic of people reselling paid plugins came up, and how it’s not only a problem for the plugin owner trying to sell plugins, but also for users because it’s impossible to get support.
I brought up that Event Espresso fairly recently put all our code on GitHub free to download, and yet (to my knowledge) saw no drop in sales. Aaron pointed out that often the payers are probably agencies who want their clients to pay for the support, so that they don’t have to (or don’t have to do so themselves). He said when he was developing sites for users, even though he often had a developer license for a plugin (so he could download it fine), he’d still ask his clients to buy a license so that they could get support directly themselves.

Getting Home to the Munchkins

I headed off Saturday night -there was a whole other day of WordCamp, but I’m religious and so wanted to stick to going to church Sunday morning and helping out with the kids- apparently the kids weren’t the most well-behaved while I was gone. It was snowing around Victoria and my home in Shawnigan, but there ended up being no delays whatsoever. The landing was a bit “exciting” though. We could feel the gusts of wind rotating the plane as it was approaching. The drive over the Malahat drive (slightly mountainous drive between Victoria and Shawnigan) was sketchy too, because it was snowing quite a bit, and the car I had didn’t have snow tires, but slow and steady got me home ok. Phew! What a Trip!

My Big Take Aways

I met a lot of genuinely nice people. There were people I talked to at WordCamp who adopted animals after the flooding in Texas; moved to an otherwise undesirable areas (where they needed to build 100 foot tall radio tower to get the internet) in order to support an aging grandparent, and people volunteering their time just because they like helping.
On a day-to-day basis, I rarely talk with someone who uses WordPress face-to-face. It was refreshing and reassuring to hear their experiences. It was also a “sanity check” hearing how others get by and about the technology they use. Not only was I getting out and socializing, but it was all productive and really interesting topics. (I just don’t get as excited over hockey etc.)
Also, I kinda assumed we at Event Espresso would be doing thing in a much more amateur way than big professional companies. But then I heard basically of Seattle times, Disney, and Microsoft managing their sites in basically just the same way. I realized we’re not just dudes at home in our pyjamas pretending to be software developers, we are actually neck-in-neck with the big guys (in addition to working from home in our pyjamas).
It also surprised me how open, informal, and fun all these professionals were! At the beginning Larry, the co-organizer, pointed out his mother named him Lawrence, imagining him in a suit with a name plaque on his desk, instead he was here wearing a bright orange shirt and a beanie cap with a propeller on top. But despite all that silliness, there were actually people with big reponsibilities (like maintaining Microsoft’s blogs and the Seattle times, or keeping 23% of the internet that runs WordPress safe) in attendance, and this was actually a big deal.

My WordPress and PHP development Setup

https://cmljnelson.blog/2017/12/19/my-wordpress-and-php-development-setup/ December 19, 2017

4 minute read
I primarily work on the WordPress plugin Event Espresso for my living, and thought I’d share my development setup: what tools I use to make software. I do this to share the tools I’ve found handy, but also inviting feedback on how it could be improved.

What I Like About My Development Setup

- I use Windows 7 would you believe it, still, because the free upgrade to Windows 10 didn’t really entice me with anything

- I have a virtual machine (VM) that’s running Linux Ubuntu (which is nice because this Linux virtual machine is a similar setup to many web servers)

- that VM is setup to keep folders in-sync with my host machine, Windows. So I can see and edit the files locally and then the files on the VM get updated

- that VM has multiple WordPress sites on different domain names that only I can access, each one running a different version of PHP

- I have PHPStorm setup on my machine for code editing. This helps me find PHP classes and know what functions they have, avoid syntax errors, and helps me keep my code cleaner than I would in a regular editor like NotePad++

- The VM has phpunit installed so I can write and run unit tests for WordPress and plugins. These automated tests are not only handy for verifying code works, but I especially like how they help me know when I (or sometimes, someone else!) breaks the existing code

- The VM has xdebug which I setup with PHPStorm, so I can mark a breakpoint in the code, which allows me to inspect the variables and watch exactly how the code gets executed, even during unit tests

- The VM has xdebug and webgrind on it, which helps me profile the code and find the bottlenecks (I’ve found that identifying the bottlenecks and fixing them works SO MUCH better for speeding up the software than just trying to optimize everything, because the bottlenecks sometimes make the code run several times slower, whereas the small optimization’s here-and-there only speed it up by a 1%)

- I also have a PHP PSR code sniffer (used when working on Event Espresso code), and a WordPress code sniffer (used when working on WordPress core code or other plugins), integrated with PHPStorm which helps me know when my code doesn’t meet the project’s standards

- I set up my WordPress installs to be git repos, which allows me to switch branches with ease (eg switch to WordPress 4.2 and then back to the latest Beta)

- I actually just use Git Bash for running Git commands, not any fancy-er GUI like GitKraken or SmartGit. I’ve used those but so far prefer using the command line directly. The command line allows me to easily use git blame and git bisect (which, last I checked, I couldn’t figure out how to do with SmartGit, although I bet they support it somewhere). What’s more most of the documentation I find always refers to the command line, so in that way it’s a bit easier. Also, if there’s an error, I know it’s an error with Git, I don’t have to wonder if it’s a problem with my GUI.

- My host Windows machine has a small program called “Dexpot” on it, which gives Windows multiple desktops like on Mac and Linux. This way, I set up PHPStorm in the first desktop, a web browser (usually Firefox) in my second desktop, a bunch of terminal windows (actually, Git Bash windows usually, which have a lot of Linux-type commands but on Windows), and a database program (HeidiSQL, in my case; just because it’s pretty lightweight, does what I need, and doesn’t require installing the entire .NET framework like others do). I set up Dexpot so all I need to do is press F1 to go to the first desktop, F2 to go to the second, etc. I have a second monitor but really don’t use it much because having multiple desktops meets my needs

How Did I Get This Setup?

Setting up each of those tools could be a tutorial unto itself. Actually, there are tutorials and resources for each.
Here’s the resources I’d recommend for setting those up:

1. Go to the vvv page for instructions on how to set a VM that’s ready-to-go for WordPress development, handling multiple versions of PHP simultaneously and xdebug (heads-up: you’ll need to setup virtual box, or another program for running VMs, and vagrant, a program for setting up standardized VMs like vvv)

2. Read this detailed blog post on how to setup PHPStorm with xdebug

3. Here’s some instructions on setting up PHPStorm with a code sniffer

Things I don’t have that I’d Like

1. Ability to access the VM from a different machine (like my phone) from the network

2. More speed! On VVV 2.1, a WordPress website with no plugins active usually takes 2 seconds to load a page; but once I load up a ton of plugins on it the requests take 5-10 seconds

Summing Up

My favourite tools are having an IDE to help me figure out where PHP classes are and how to use them, code sniffers to help me format the code correctly, and xdebug integrated with my IDE so I can step through the code.
I hope this gives you some ideas on how to improve your programming setup. While it’s a pain to set things up, I think each of these tools helps me be a better programmer.
Questions? Is your setup better? Tweet me or comment!

Most WordPress Users Don’t Care about Free Software or Community

https://cmljnelson.blog/2018/01/17/survey-says-most-wordpress-users-dont-care-about-freedom-or-community/ January 17, 2018

5 minute read
(They Just Want Their Website to Work)

Or at least that’s what I understand from the 2015/2017 WordPress users survey results.
I was under the impression that WordPress’ key to success was its embracing free, unrestricted software and its huge community, but it seems those features aren’t a priority for 80% of it’s users.

Why Do We Use WordPress?

Because it’s easy or customizable, according to 81% of respondents (49% said “ease of use” and 32% said customizability, to be precise). Only 11% thought software freedom was the most important aspect, and only 9% thought the huge WordPress community of volunteers was the main reason for keeping them.
That sounds like very shallow commitment to me. What happens when the 49% of users who prioritized “ease of use” discover there are actually many easier ways to build and maintain a website? (It’s almost objectively easier to use a hosted solution like weebly than to find hosting, setup WordPress, install plugins, and verify nothing gets broken by the near-daily upgrades). Or what about when those who prioritize customizability discover another more customizable system? (Developers love Drupal and Joomla, whereas most belly-ache about WordPress) It seems like a matter of time before they realize that, if they only care about those things,  better alternatives exist.
That’s part of the point Brian Krogsgard made when he interviewed Matt Mullenweg at WordCamp Europe 2016 (jump to 11 minutes in): WordPress used to be the easiest solution out there, but easier solutions have come up. But Matt responded by asserting that WordPress’ real success was more because of its “flexibility and community”. Does the survey data support that? Yes and no.

Is Flexibility a Priority?

Does flexibility matter to WordPress users? Very much so. 60% of respondents said their sites are so customized that you wouldn’t even know it’s WordPress (at least when visiting the site, site administrators can tell). 28% of users said plugin/theme issues were the most frustrating thing about WordPress, (the next most frustrating thing was security, which only got 11% of the votes). So most users have a very customized site, and they care more about those customizations working than security. But it’s also the most frustrating part about WordPress.

Is Community A Priority?

Survey respondents said only 5% of companies involved in WordPress contributed or attended WordCamps. Only 4% contributed bug reports or patches. That doesn’t sound like a lot of involvement.
While 25% of WordPress professionals have written their own theme, less than 10% have attended a WordPress meetup, submitted a bug report, attended a WordCamp, contributed to documentation, or submitted a patch. Imagine how much better WordPress would be if they all did!
Having said that, WordPress’ community is alive and well, even if only no more than 10% of users are involved. There are still over a thousand official meet ups globally and almost a half million members of those meetups.
And to be fair, it’s likely that if respondents don’t prioritize community involvement, they surely all appreciate that community’s work: the code, the documentation, or help forums, etc. So community probably matters, but it’s certainly not a top priority, even for WordPress professionals and companies.

What About Freedom?

Only 10% of respondents reported their favourite part of WordPress was that it’s free. It’s not a priority, but it should be.
First, by “free” I don’t mean just free of charge, but that you can use the software for whatever you like (ok there’s a big exception relating to the GPL). So you can use WordPress to make money in whatever way you please. And no company can surprise you by changing their terms of service, or suddenly increasing prices.
That’s not the case if you have a website with weebly or any other restricted software. In fact, that’s how WordPress got it’s start: there was a very popular blogging platform called Movable Type that suddenly changed its pricing structure, which led to a mass exodus from it to WordPress’ haven of freedom.
That story continues today, with companies like EventBrite raising rates and changing terms on users, which reminds them of the value of software freedom.
What’s more, with WordPress you own your data and are free to do what you wage with it. This means you’re also free to stop using WordPress and take your data with you. Many web sites running non-free software allows this too out of a bizarre self-disinterest, but they have no requirement to do it. If you have a website on weebly, “your” website data actually belongs to them. If you want it back you need to ask very nicely, and make sure you ask for it before they go out of business (or are acquired by another company and then shut down) and all that data is lost.
Running your website using free software on your own server is the digital equivalent to owning your own house, whereas using restricted software on someone else’s site is more like renting. If you rent, be aware the rates may change, and they may ask you to leave at any time. (Actually, in most jurisdictions, there are laws protecting home renters, but rarely are there any for software “renters”).
So free, unrestricted software can be critical, but usually we don’t appreciate it until it’s too late.

Is Software Maintenance a Priority?

Respondents were less concerned with updates breaking their sites than I thought they’d be. Only 6% thought updates were the most frustrating thing about it. And though 27% said updates make them nervous, an equal portion said they’re not nervous.
So updates make many users nervous, but there doesn’t seem to be a strong tendency towards liking or disliking them.

Incentivized Respondents

In 2015 there were 45,000 survey respondents, but during the two subsequent years, 2016 and 2017, that number dropped to about 16,000. I wonder what caused the 66% reduction in respondents two years in a row?
One probable factor was after the survey results stopped being published. Folks asked themselves “whats the point in responding if I won’t be able to see the results?” We didn’t care about providing information just to the WordPress Foundation to help them make better decisions– we wanted access to the information ourselves so we could make better decisions. Once again, it seems 66% of us just want the end results, we don’t care too much about giving back to the community.
(Given that the results were just published, we’ll see if I’m right, or if it was another factor at play, in the 2018 survey results.)

Ironic, Given Our Age

94% of WordPress users are over 20. That means many of us are parents, or have lived in this Earth long that we’ve learned and earned something that we want to share with future generations and the world. But it seems despite all our criticism of the rising generation being selfish and unaware of what’s going on around them, all of us old timers are actually also still looking out for #1, not the community.
(And why are there so few young WordPress users? I find that statistic disconcerting.)

Conclusion

I think despite the active WordPress community, there is a lot more that could happen, and a lot more WordPress users could benefit from participating in it more actively.
Users also don’t too aware of the dangers of non-free software, and more education on the subject could be good (I for one took a while to come around to it).
On caveat: it’s hard to draw any real conclusions from this survey, because there’s always the possibility that there was self-selecting bias in the respondents.

Follow-Up Questions

The answers provided by the survey results have given rise to new questions for me:

- What part of using plugins/themes is the most frustrating for users? (Compatibility? Configuration? Usability?)

- How can we get more young users?

- Why do only a tenth of users attend WordCamps or meet-ups?

- Why don’t more users contribute to WordPress? Conversely, what motivates those who DO contribute?

If you have more answers, let me know in the comments!

The 5 Things You Get From a WordPress Meetup

https://cmljnelson.blog/2018/02/12/the-5-things-you-get-from-a-wordpress-meetup/ February 12, 2018

9 minute read
This post originally posted in the Cowichan Valley WordPress Meetup blog.

Attending a WordPress meetup takes time from doing what you love or what makes you money, so why bother? (The same goes for attending a WordCamp, which are really big, once-a-year meetups, but I’ll focus on meetups here.) And why do people bother organizing meetups, which take even more time and effort?
I’ve spent many years wondering about these questions. I’ve even wondered while in the process of doing them: “why am paying for a flight, taking a whole Saturday away from my family, and inconveniencing my wife, in order to go to a WordCamp?” Or “why am I putting all this effort into organizing a local WordPress meetup? And why should anyone even come?” For a long time my only rationale was “it seems most of the big names are doing it, and it feels like the right thing to do”. But I’ve recently realized some concrete benefits of attending a WordPress meetup.
The reasons boil down to the 5 things participating in a meetup get you: a better website, knowledge, reputation, friendships, and good karma.
A WordPress Meetup Gets You…

A Better Website

At WordPress meetups, we talk primarily about using WordPress to build web sites. Many attendees have a website that they are building or maintaining, and they hope to get help in doing that. For example, maybe you’re using a WordPress website someone else built, and you’re dizzied by all the options and terms in WordPress. Or, worse yet, you started changing things and broke something, so you’d like help fixing it. Or, maybe you’re building a new website and you want to know how to make it look a certain way or do a certain thing. So you’re probably coming to a meetup to get answers to your immediate questions. That’s fine. (Just realize volunteers aren’t guaranteed to always be right, or available). At the Manchester, England, WordPress meetup they always dedicate the first part of their meetups to just answering questions and helping folks with their sites. If folks want to leave before they start presentations and other things, that’s fine, no hard feelings. They just want a little help, they don’t want to become full-on web developers.
However, this might not be the reason some people come. I, for one, mostly just help create and support plugins- I’m not usually building a particular website. So my motivation for attending is otherwise.
On a related note: a meetup is usually not an “introduction to WordPress” course, because many attendees are already fairly familiar with it. Instead, it’s an opportunity to continue learning about WordPress and share your experiences. It is supplemental to your own learning. If you’re just getting started you’re welcome to come and we’ll try to guide you to resources to help learn it, but you may want to consider taking a course (in-person or online).

Knowledge

Others come to a meetup primarily to learn, not necessarily because they’re looking for immediate help with something. They might use what they learn on a website, but they could also just be learning all they can in order to use it on future websites, to create products to sell to WordPress users, or to keep current on what’s new.
On the other hand, some people don’t really care to learn all they can about WordPress- they’re passionate about something else, so they only want to know what they need to get their website to work, and that’s it. That’s ok. And others feel like they already know everything they need to about WordPress, and the web, and entrepreneurship, so they don’t think they’re going to learn much. In some cases, they might be right- although teaching is an important part of learning. My next point addresses that.

A Reputation

For folks who feel they already know everything WordPress they need, they might be participating in the meetup to build their reputation. When you present at a WordPress meetup, it gives the idea that you know more than the average joe about it (presenters know that’s usually not true to begin with, but you do learn a lot in the process of presenting, so it might be a self-fulfilling prophecy). If you are an organizer of a WordPress meetup, that speaks a bit louder than just telling potential clients “I’m a WordPress expert”.
Can you build your reputation as an expert by building websites yourself, or as part of your day job? Sure. But it’s easier to start participating in a meetup than getting a job using WordPress. The only requirement is usually just to show up, no previous expertise required. Eg, you could help organize a meetup by presenting or helping to let members know when the next event is. The current organizers will probably be happy to have your contributions, whatever your experience.
Meetups are also better at building a reputation than commercial endeavours because they’re a bit more high profile. Because they’re not for profit, they get access to a lot more support from the community. WordCamp central pays to put them on meetup.com, meetups often get access to venues for free, companies will make donations to them just for the association, they get access to community resources like public message boards, and people are generally more likely to attend or spread the word if they know there are no strings attached.

[Image removed]

When I spoke at WordCamp Seattle, my blog and twitter profile saw a significant spike in activity (relatively, I’m still no big deal, by any means). That’s because many of my tweets related to that big event, and so my name got attached to it, plus they basically retweeted everything I posted. Presenting at, organizing, or sponsoring a meetup will help build your reputation.
Some attendees of course really don’t care if they have a reputation in the WordPress world -WordPress is a relatively minor tool they use in their profession, they just want to know how to use it. That’s fine (we aren’t all going to become mechanics or chefs, similarly we aren’t all going to be known as WordPress experts). They don’t care what the world thinks of them, just what their friends and family think… I feel another segue coming on…
Friendships

It’s easiest to make friends with people with similar interests, or those with whom you’ve undergone a traumatic event. Well, the folks at meetups are similarly interested in WordPress, and have probably endured their share of traumatic events with it (eg had a website broken because of an update, gotten hacked, or spent hours finding a missing semicolon). Plus, there’s a particular breed of person at WordPress events. From my experience they’re unusually friendly, helpful, and interesting.
Eg, I had a series of amusing encounters regarding presenting at WordCamp Seattle 2017.

- First, I contacted a fellow presenter, Devon DeLapp, asking if he’d like to practice our presentations with each other. We had never met before, but we spent several hours preparing with each other over Google Hangout anyway.

- For my WordCamp presentation, I prepared a silly video with another fellow WordPresser: Boone Gorges, a lead developer of BuddyPress. Likewise, we didn’t know each other, haven’t met in person, and actually haven’t even had a video call, and yet made a short film together.

- Lastly, after the presentation, for some reason I didn’t get my much-sought-after badge on WordPress.org. Mark Root-Wiley quickly fixed the situation and provided this amusing visual proof.

[Image removed]

What’s more, there’s a unique mixture of nerds and supposedly-normal-people. That’s because WordPress is positioned as being particularly easy-to-learn, so most of the developers were once normal-people and usually learned programming or design on the side. And many of the normal people may one day find themselves learning a lot more code than they previously imagined. Sometimes nerds will think non-nerds are dumb for not knowing what a “domain name” is, and sometimes non-nerds with think the nerds lack social skills, but there’s a lot less of that in WordPress than what I’ve seen elsewhere. The WordPress community is generally a really friendly place.
Of course, many attendees have got all the friends they need, and while they’re friendly, that’s not why they come. There’s no obligation to go on any WordPress-buddies road trips or share meals or anything, but they may still find themselves making friends anyway. Especially if they’re doing the next item…
Good Karma

Many meetup attendees aren’t necessarily looking to improve their own website, or build their own knowledge, or boost their own reputation, or get tons of friends. Many come simply to help others: to improve others websites, share what they’ve learned, boost others reputations, and help others to have friends. Initially, this motivation is the most unclear. But it makes sense in terms of practical, non-spiritual karma. You don’t have to be Hindu to grasp the idea. Wikipedia says this about karma: “good intent and good deed contribute to good karma and future happiness.”
When I’ve helped answer someone else’s question about using the WordPress REST API, guess what? I’ve learned (usually because I hadn’t thought to ask their question, or hadn’t faced their problem before). When you teach something to others, you become aware of all the parts you actually don’t understand very well. In order to explain something very simply, you need to understand it very well. So teaching others fortifies your own understanding (and may actually be essential for any long-term retention). When you help improve someone else’s reputation, and they become successful, guess who they’ll credit? Probably themselves. But after that, they’ll put in a good word for you whenever they can. And what’s the best way to make friends? From my experience, by trying to be a friend to others.
So realize if you’re just coming out to help others, usually all that good karma will come back to you (even though that wasn’t your intention… it’s ironic, I know).

Come Get Some!

So, maybe you’ve previously attended a meetup looking to build one of those things. I’d suggest there’s more to be gained by trying to build one of the others. Eg, did you get answers to your questions about how to build a website, got it built, and then thought there was nothing more for you at a meetup? Maybe you could come and start looking for other things to learn for future endeavors. Feel like you’ve already learned everything there is about WordPress? Well, make a name for yourself by teaching to others. Gotten bored with just technical stuff? Maybe try to make some good friendships. Or simply don’t think there’s any benefit to you by going? Maybe try going just to help others, and you’ll just feel good (and maybe stumble upon other benefits too).
So that’s my list of things you get at a WordPress meetup.

Things You Don’t Get at a WordPress Meetup

Now, here’s a related, briefer list: things you should not expect to get at a meetup.

Money

You won’t get paid for participating, presenting or organizing. No, money’s not evil. But we have extra trust at a meetup because it’s understood that we’re all there to improve ourselves and help others, not to make a buck.

Clients

Don’t come to a meetup in the hopes that you’ll sell your product to attendees, or get them as clients for whatever work you do. Those might be welcome side effects, but actively trying to sell something while at a meetup will turn people off you and the meetup. If they ask, feel free to tell them, but don’t start handing out flyers. It similarly destroys trust. (This point might be different for a WordCamp, I’m not sure. The situation is a bit different because sponsorship is pretty expensive and many employees travel a long way to attend them… so explicit salesmanship is a lot more commonplace.)

Infinite Support and Service

Just like developers shouldn’t go looking for clients at a meetup, the rest of us shouldn’t expect to get infinite free support at them, nor should we expect others to drop what their day jobs to help us design our website.
Although you get some free help at meetups, it’s limited. After the meetup, eventually, we want to return to the rest of our lives. So although we like helping others with their problems, if you’re asking too much and it’s starting to be onerous on us, eventually we can’t give any more free support or service. At that point, you should start looking to hire someone. Maybe there is someone you could hire from the meetup, but you could look on upwork.com or anywhere else, but you’re asking too much for free.

Product Placements

If you’re a sponsor of a meetup (eg you provided the venue, or website hosting, or pizza) does that mean you basically bought advertising? The answer here can vary from meetup-to-meetup, but basically: you bought getting your name mentioned in connection with the meetup, maybe put on the website, and maybe a one-sentence description of what you do. You don’t get the email addresses of everyone in the meetup, nor a 2-minute sales-pitch, or our undying loyalty.
You’re an unaffiliated person or organization who’s done something nice for the community, and the community will know about it, but you did not buy advertising.

A Pit for Your Competitors

One strange thing about a WordPress meetup is that many of the attendees are actually in direct competition: many make their livings by building websites, just the same as many other attendees!
I help build event registration plugins, and often collaborate online with developers from competing businesses in building WordPress.
This is a bit awkward when you have a mentality of scarcity; ie, every dollar they earn is a dollar you don’t. But when you think about it: although WordPress runs 29% of the Internet, there is still a whopping 71% it doesn’t. So if your contributions to WordPress make it run 1% more of the global market, both you and your competitors in WordPress benefit. Also, there’s a ton of the economy which basically has no web presence, or a very poor one. If they get online, then that makes the internet bigger, and will similarly benefit you, your WordPress competitors, and users of other web software. So with that mentality, you’re actually more partners than competitors.
So, if you contribute to your local meetup, or sponsor it, that doesn’t mean the meetup organizers have signed an agreement to not accept contributions or sponsorship from your competitors. So don’t give to the community in order to dig a pit for your competitors.
In fact, by helping build the WordPress ecosystem, you might help your competitors (and they can freeload on your contributions without giving back). So why would you bother? Because “a rising tide lifts all boats”, and although your contributions are free, they’re not anonymous. It’s not too hard for people to tell who’s the free-loaders and who’s the leaders.

Summary

Phew! That’s it. The five things you build by going to a meetup:
websites, knowledge, reputation, friendships and good karma.
Five things you won’t build: money, client list, unlimited free support and service, advertising, or a pit for your competitors.
Did I get it right? Lemme know in the comments.

Mistakes Non-Developers Make When Using WordPress Plugins

https://cmljnelson.blog/2018/03/20/mistakes-non-devs-make-when-using-wordpress-plugins/ March 20, 2018

12 minute read
WordPress plugins can customize your WordPress site in nearly any way. But there are some mistakes non-developers make when using WordPress plugins and hiring developers to make them. This article explains five such mistakes to avoid, and how to benefit the most from WordPress plugins.

Avoid Expensive Custom Development

The most expensive part of making a website is having experienced developers do custom work on it. Where possible, it’s much cheaper to use pre-built WordPress plugins and themes, even ones that aren’t free. If you can make due without custom development, your website will be much cheaper.
Let’s talk specifics: how much might you spend on a WordPress website in the first year? Here are some ballpark, theoretical figures.

[Image removed]

Ballpark cost estimates for various website elements for a very small website ($50/hour is a typical rate on upwork.com, and 16 hours is the amount of time some simple plugins could take; some complex plugins have taken thousands of hours to develop)

Getting a developer to do custom work (eg write custom code) is easily 10x the cost of using a pre-made WordPress plugin or theme.

Maybe You Don’t Need a Plugin Anyways?

Better yet, before you even look for a WordPress plugin to do something, make sure WordPress core doesn’t already have an option for it. Maybe it can be done using one of the dashboard’s settings pages or the Customizer. Not only is making use of the tools WordPress already provides free, but it also requires no extra maintenance down the road. Only after verifying WordPress core doesn’t provide the customization you need, it’s time to search for WordPress plugins.

[Image removed]

If the WordPress customizer can do the customization you need, it’s usually best to use it rather than a plugin

Stick to Pre-Made WordPress Plugins If You Can

WordPress plugins are files that can be added to your WordPress website that allow it to do extra stuff. A bit like apps on your phone, or programs on your personal computer.
There are thousands of WordPress plugins, and most likely there is one that will meet your needs. While many are free, even the paid ones are still a fraction of the cost of custom development.
There is a good example from my day job at the WordPress plugin shop, Event Espresso. Downloading pre-made payment gateway integrations from us (WordPress plugins for accepting payments using a particular payment gateway, like PayPal or Stripe) can be downloaded for about $80 each. In comparison, a custom-built payment gateway integration (one that works with a new payment gateway) will cost at least $1000. So if potential clients have a limited budget, and they don’t mind using a payment gateway with which we’ve already built integration, we really discourage custom-built payment gateway integrations. We want to avoid having our users be disatisfied having spent about $100 for our main plugin, Event Espresso, which provides almost all their event registration needs, but then spend a whopping $1000 on the relatively minor payment gateway integration.
(By the way, $1000 is actually cheap for that custom development. We offset our expenses by making the plugin available to others for purchase for $80 by others afterwards. If we didn’t do that, we’ve had discussion about increasing the cost to $5000, depending on the payment gateway.)

Customizing Pre-Made Plugins is Also Costly

So when it comes to costs of pre-made WordPress plugins vs custom-made ones, the rule of thumb is:

90% of functionality is done by a pre-made plugin and will cost 10% of the total; the last 10% of the functionality is done by custom development and will cost 90% of the total.

So if you’re on a tight budget, and can make due without that last 10% of functionality which costs 90% of your total expenditure, stick to using pre-made WordPress plugins. If not, the cost goes up unnecessarily, and significantly.

Question to Consider: When would you hire a developer instead of using a pre-made WordPress plugin?

Don’t Get Themes to Do The Job of Plugins

Another main feature of WordPress is it’s mobility: the ease with which you can change your website’s theme if you want a fresh look. But this mobility is endangered when themes add functionality, instead of just style.
For example, let’s say 5 years ago you found a great premium theme that adds a page-builder, which makes creating and editing pages easier than using WordPress’ built-in editor. You were happy with it for a few years, then mobile-first themes started becoming popular, and you realized your theme isn’t that mobile friendly, so you want to switch themes. When you switch themes, suddenly all your pages become a mess of indicipherable code, because they need your old theme’s page-builder to be displayed correctly. So, in order to fix your site, you switch back to your old theme.

[Image removed]

This is called “theme lock-in“: where you’re unable to change themes without totally breaking your website. If a theme offers functionality (eg add a drag-and-drop page-builder) it sounds simpler than finding a plugin to do it, but it’s a bit of a trap.
It’s best for:

- WordPress plugins to add functionality (control what your site does)

- themes to add style (control how your site looks)

If you instead use WordPress plugins for adding functionality, you’re free to switch themes at any time.

Question to Consider: what features do themes sometimes add that create theme-lock-in. Are they ever justified?

Don’t Expect Free, Quality Support

There are lots of places you can get WordPress plugins. Paid ones are not necessarily going to be better than free ones (despite the fact paid ones are often called “premium WordPress plugins”). The one thing money will get you is better support, and ideally, with WordPress plugins, that’s what you should be willing to pay for. If you expect high quality support for free, you may be dissapointed.

[Image removed]

The mess of woodwork supporting the dock at our local Cowichan Bay.

A quick review, where can you get plugins from and how are they different?

Shady Plugin Reseller Websites

First off, it’s often possible to buy a premium plugin from a “plugin reseller”, that is someone who isn’t the plugin’s author: they’ve just bought it and are reselling it for a major discount. It’s cheap. Sometimes you’ll even find the plugin for free. But that reseller also won’t provide you with support, help fix any bugs or make improvements you suggest. Additionally, they may add malware to it. In summary, they:

- are cheap or free

- aren’t reviewed by anyone, and may have malware added

- provide no support

Stay away from shady plugin reseller websites!

WordPress.org Plugin Repository

The best known source for WordPress plugins is the wordpress.org plugin repository. This is also what you see when you search for plugins within your WordPress website’s “Add New Plugin” page. These plugins:

- are free to download

- are reviewed by the WordPress Plugin Review Team

- have free support

Support is free, but it’s also voluntary. Plugins are usually put here in order to create more awareness about the authors, or to serve as demos for “premium” versions you can purchase elsewhere.

Envato/CodeCanyon, or Other Premium WordPress Plugin Repositories

These are sites likes codecanyon.net. These plugins:

- require payment to download

- undergo a code review, but its criteria is harder to find

- usually have paid support and updates for 6 months, which can be renewed

Given that you’ve paid for support for these plugins, the plugin authors are more incentivized to be responsive. However, because you need to pay to download these plugins, other developers can’t easily access them to review the code and check for compatibility bugs. The result being these often have more bugs than you would expect.

Plugin Author’s Own Web Sites

Many plugin authors have their own websites, where you can pay to download their plugins. A noteable example of this is Gravity Forms. These plugins:

- require payment to download

- don’t necessarily have a code review

- usually have paid support and updates for a year, which can be renewed

These plugins generally have a better reputation than those found on premium plugin repositories. A possible reason is simply that the plugin author’s need to have put more effort into making their own website than those who rely on the premium plugin repository’s site. However, they still suffer from the same problem as other premium WordPress plugins: it’s hard for other developers to review them and check for compatibility bugs.

GitHub, GitLab, or Other Code-Sharing Repositories

WordPress plugins can also be found on github.com, gitlab.com, and other code-sharing repositories. These plugins:

- are free

- have no formal code review, but the purpose of code-sharing sites is to facilitate peer review and feedback

- have free support, but it’s geared towards developers

These websites are excellent for finding free, useful plugins, and they specialize in allowing other developers to review, check for compatibility bugs, and contribute to improve them. The only downside is the support is usually reserved for other developers who will be contributing to the WordPress plugins. Everyone else should not expect free support.

Support Is What You Should Pay For

So there are lots of free and paid options for downloading WordPress plugins. Free plugins also offer free support, but it will be limited because it’s offered by volunteers. Paid plugins usually have better, more incentivized support, but their code is kept hidden away which leads to more bugs. So they both have issues- is there a better solution?
Ideally, you should be able to download plugins for free, and only need to pay when you need support. This way the plugin gets used lots and other developers can easily review it and improve it, so there should be fewer bugs; but users who need premium support have that available to them, which helps the developers earn a living too. This is our approach at Event Espresso:

- our main plugin and most of its add-ons are available for free from GitHub, but support there is limited only to developers; this way other developers can try it, review it, and contribute easily

- we offer paid support for our main WordPress plugins and all its add-ons from our website, for regular users who need timely support

Paid Support Is Worth It

Also, don’t begrudge paying for support and maintenance of a plugin. It’s still cheaper to pay $80 a year for a plugin than hiring most developers to maintain a custom one (which could likely be about 10 hours at $50/hour, so $500). Paid support for a plugin gets you:

- Help using the plugin

- New features

- Updates so the code continues to work as WordPress and other software continually changes

- Bug fixes

If your business depends on your website, and your website depends on a plugin, make sure you’re not relying on the plugin authors goodwill to maintain and support it.
If you download a premium plugin from someone other than its author, it’s legal to use it and share it (there’s a lot more to be said on that). But realize that you will not be getting any support from the plugin’s author.

Question to Consider: if you could download a plugin for free, would you still pay for support? How would you decide?

Don’t Isolate Yourself From The Community

[Image removed]

Another differentiating feature of WordPress is its helpful community. If you don’t get help and involved in that community, even when choosing and using WordPress plugins, you’re going to miss lots of time-and-money-saving opportunities.
Online Community Help

So if you’re wondering which WordPress plugins will best meet your needs, it’s ok to ask around for tips. The WordPress Support Forums are a great, free resource. Ask a question, and a few people will chime in with some advice. Although respondents aren’t making any money directly, by helping they’re getting experience, exposure to potential clients, and an improved reputation.

In-Person Community Help

Going to a WordPress Meetup is also a great place to get answers to your questions. Although the help you get there will be limited to probably a monthly meeting, the whole point of those is to discuss WordPress and related stuff, so discussing what you’re having trouble with is a perfect fit. I wrote a whole other post about what you get from a meetup.

Professional, but Free, Help

Lastly, it’s not a bad idea to get free advice from premium WordPress plugin and theme authors. Of course they’re biased towards their products, but they’ll also realize when their product isn’t a good match. At Event Espresso, when potential clients are inquiring about how well our plugins will meet their needs, if we see we’re not a good match, we’ll tell them so. I think most developers will do the same. We’d rather you have a positive experience with us, and possibly come back later, than struggle forcing our plugin to do something for which it’s ill-suited.
I’ve found that when I work in isolation, being unaware of what others are doing around me, I make weird decisions (like thinking it’s ok to hack WordPress plugins or core files and other faux-pas). Getting community feedback is a sanity check, and is what WordPress veterans recommend.

Question to Consider: what other ways can you get feedback from the WordPress community?

Avoid Working With Developers Without an Open Source Track-Record

When you must hire a developer to help customize your website or write custom WordPress plugins, there are thousands of WordPress developers available for hire. Choosing ones with an open source track record will lead to better results.

What is an “Open Source track record”?

An “open source track record” includes:

- Contributing code, documentation, translations, etc to WordPress core

- Maintaining a WordPress plugin or theme, preferably one on wordpress.org

- Teaching at WordCamps and Meetups (yes, that’s a plug for getting presenters at my local meetup!)

- Helping others use WordPress, like in the WordPress support forums

Why Is an Open Source track record valuable?

Doing those things show the developer:

- Is familiar with WordPress code

- Their code or knowledge has been reviewed by peers and approved

- Plays nicely with others (open source takes a lot of collaboration and communication skills)

- Is aware of the WordPress ecosystem (and how to have their code play nicely in it)

- Is probably not just motivated by money (as their contributions were probably free)

Who are the developers who know WordPress best? Probably the ones who built it. They’re the ones who will probably know the easiest way to customize WordPress in ways that won’t conflict with other plugins or themes. And they’ll probably even know about undocumented, unpublished plans, that those who are only observers of WordPress’ development don’t.

[Image removed]

Screenshot from WordPress 4.3’s release, showing some of the contributors

You can ask a potential developer if they’ve contributed code to WordPress core or what WordPress plugins or themes they’ve authored.
I think seeing open source contributions is possibly more valuable than seeing specific sites in a developer’s portfolio. The main reason is that other developers review open source and it gets held to a higher standard, whereas that’s not possible with code that’s kept secret. That type of code can hide all sorts of nightmarish problems that users don’t care about… until it causes bugs, or a new developer tries to modify it.

WordPress Developer Search Process

So, if I were looking for developer to help with a particular customization, I would:

1. Look for a WordPress plugin that did 90% of what I needed, then I’d ask if its author could do the work. Nobody else in the world knows that plugin better. If they’re not available, they’ll probably have a good recommendation

2. If I were looking for just any WordPress developer, I’d look for one who has contributed to WordPress core. Each version of WordPress mentions who contributed to it at the bottom of the release notes. I’d peruse that list for one that sounds good. Alternatively, I’d peruse WordPress.tv presenters

3. Next, I’d look for a developer who maintains a plugin or theme on wordpress.org (this is part of why developers give away WordPress plugins and themes there- it boosts their reputation which can help them get future jobs)

4. Next, I’d at least look for someone who has their own website. It always seems strange hiring someone to help you with your website when they don’t appear to have their own.

5. Next, I’d look on codeable.io, it specializes in WordPress developers. Some of its developers are WordPress core contributors (it’s a category).

If you prefer to keep it local, you can google “your area + WordPress”. You may find other sites from your area made by a particular developer. There may be someone who has presented at a local meetup or a nearby WordCamp. But regardless of location, prefer to work with someone who has contributed to WordPress in some way. If someone claims to be a WordPress professional, but hasn’t contributed to WordPress in any way, that claim is harder to verify.
And if you’re a WordPres developer who has yet to take the plunge into contributing to open source, like we all were at some point, I have a post with some tips for you, too.

Question to Consider: why do so relatively few developers contribute?

Conclusion

1. Where possible, use WordPress plugins instead of doing custom development, they’re much cheaper.

2. Don’t rely on themes to do the job of WordPress plugins because that locks you into always using the same theme.

3. If your business relies on certain WordPress plugins, pay for support and maintenance, even if you could download them for free elsewhere.

4. Make use of the WordPress community, and all the free help available there.

5. And lastly, if you absolutely must hire a developer, try to find one who has contributed to WordPress.

Suggested follow-up activities:

- Play around with the customizer to change background color (use a temporary site from poopy.life, not your live site!)

- Find a good, style-only theme

- Find a WordPress plugin that will add a Facebook like button

- Sign up forWordPress support forum account, then answer, or ask, a question

- Find a WordPress developer specializing in membership sites, preferably one who has contributed to a membership plugin or WordPress core

Let me know how it goes, and what you think, in the comments!

WordPress Turns 15: a Story of Survival, Ideals and Global Domination

https://cmljnelson.blog/2018/05/23/the-story-of-how-wordpress-survived-for-15-years/ May 23, 2018

10 minute read
After its initial release 15 years ago, the website software WordPress is used by over 30% of the websites on the Internet, whereas the nearest competitor sits around 3%. It’s prospects couldn’t be better.
Did I say that? I meant to say it’s really old software, built primarily by hobbyists and amateurs from home in their pyjamas, recently voted one of the most “dreaded technologies”, competing with software that is far easier to use, and at the core of its business model is… it’s free.
How has WordPress, the blogging software-turned-content-management system, managed to not only survive, evolve, and even thrive?

Crisis and Freedom

WordPress was actually born in crisis.
Back in 2003, the dot com bubble had recently burst and the outlook for online businesses was at its worst. What’s more, there was already an eight hundred pound gorilla in the blogging space: Movable Type, which ran 70% of the blogs online at the time.
A niche, obscure piece of blogging software, called b2/cafelog, was becoming abandonware. Its author, an unemployed Frenchman who wrote it while learning how to program, had basically disappeared. Some may have wondered if he was dead. In any case, b2/cafelog certainly was dead, just like Windows 92, MSN, and so many other pieces of outdated software. It technically still worked, but with no one maintaining it, the world and technology moved on without it, as were many of its users.
Matt Mullenweg, a Political Science student, blogger and tinkerer, lamented:

My logging software hasn’t been updated for months, and the main developer has disappeared, and I can only hope that he’s okay….
Fortunately, b2/cafelog is GPL, which means that I could use the existing codebase to create a fork (new version)… Someday, right?
– https://ma.tt/2003/01/the-blogging-software-dilemma/

That could have been the end of it. But one of his followers, Mike Little, offered to help.
Between exams and posting photos of his cat, Matt and Mike took b2/cafelog’s code and created a new version. One of Matt’s friends suggested a name, probably inspired by CafePress or Movable Type: WordPress.
The initial release improved on b2/cafelog mostly by bringing it up-to-date with the XHTML standard, but that was mostly it. In terms of the software, it wasn’t a huge improvement. But the software did manage to survive, and that was the key.
Unlike so much other software, b2/cafelog was what’s called “free software.” Software always comes with a license, dictating how it can be used and distributed, just like films, music, art, etc. Usually that license says who created it, forbids others from modifying it, and allows only its author to distribute it.
“Free software,” on the other hand, is special in that its license (called the GPL, or GNU Public License) dictates that you can use it for whatever you want, with whatever modifications you want, and you can even distribute the copies you make. Freely. This is why b2/cafelog was able survive even though its creator disappeared. Matt said:

because we had [the] freedoms [of the GPL], Mike Little and I were able to use the software as a foundation, giving us a two-year headstart over building something from scratch, and realize our own vision of what blogging could be.
– https://ma.tt/2014/01/four-freedoms/

Schism

So although b2/cafelog was surviving as WordPress, its software license also caused a schism: there were other copies (also called “forks”) of b2/cafelog that were being created. This was fragmenting the already-small niche community. b2evolution and b2++ were created by others and had other features.
Rather than try to drive the competition into the dirt, Matt reached out to their authors and asked them to instead contribute their work into WordPress. With a lot of diplomacy, a quality for which computer programmers aren’t particularly well-known, Matt was able to eventually win over one. b2evolution became WordPress MU and was eventually merged into the main WordPress project. Its author also became a contributor to WordPress.
Another fortuitous event happened soon after: b2/cafelog’s old author reappeared online, and announced that b2/cafelog was discontinued, and that WordPress was its ordained successor. WordPress had now not only inherited b2/cafelog’s code for free, but also most of its community. But the software was still hobbyist software, used by a small niche of bloggers who liked the technical challenge of running the software themselves.

Movable Type Migration

Meanwhile, Movable Type was blogging software being developed by a team of professionals, with a business model, and a software license which gave them ultimate control over it. And they had decided it was time to cash in on their significant market lead.
Its creators, Six Apart, made a subtle but significant change to the software’s license, which meant some users had an unexpected price jump. While this was perfectly legal, and quite reasonable for the company, it was also reasonable for many of its users to start looking for alternatives. They found WordPress.
The change was announced on the tech news website SlashDot, and traffic to WordPress’ website went threw the roof. The site crashed several times because of it. WordPress lacked many of the features of Movable Type, but had one users suddenly realized was very important: it was free software. Not just in terms of price, but also in terms of its license.

I have been receiving emails all morning asking if I have any plans to charge for WordPress in the future. The answer is no, but my answer doesn’t matter. The license WordPress is distributed under —the GNU Public License—ensures that the full source is available free of charge, legally.
– https://wordpress.org/news/2004/05/new-pricing-scheme/

That was the tipping point in both converting Movable Type users into WordPress users, and supercharging WordPress into a major player in the blogging space.

Democratize Publishing

Matt was a big believer in blogging. He wanted all his friends to express themselves on their own blogs, free from any restrictions that a company would place on them. His vision for WordPress was that it would “Democratize Publishing.” Another way of saying that, is that WordPress’ sought to allow everyone to:

- publish whatever they want,

- know what the software is doing behind-the-scenes,

- be able to change the software,

- be free to distribute their improved version to others

This was a fairly tall task: running your own website simply is not an easy task, especially for the less technically-inclined. WordPress doesn’t just try to make blogging easy, it tries to make setting up, customizing, and maintaining a blog easy. That would be hard for any company, and especially an ad-hoc group of volunteers.
Steps were taken to try to simplify the process of setting up WordPress, which eventually grew into WordPress’ “Famous 5 Minute Install“, and by 2005 some hosting providers (companies that rent servers) took care of installing WordPress automatically.
Speaking from my experience of setting up websites with other self-hosted software (that means software you install on a server yourself) this was revolutionary. So much so, that perhaps many users chose WordPress even though an alternative may have had more of the features they wanted.
Another early improvement in WordPress was how customizations were made. At first, users needed to dive into its code and make the changes they wanted. While this was better than other software which doesn’t allow you to change it at all, it wasn’t too much better because it was so difficult to do and so laborious to maintain. Every time WordPress came out with an update, users needed to re-apply their hacks.
The idea of “plugins” was born: separate software that ran alongside WordPress, that modified it, but wouldn’t be overwritten when WordPress was updated. This was really convenient for tech-savvy developers able to read code.
The WordPress Plugin repository also helped forward the mission to “Democratize Publishing.” It made plugins easily available to non-developers (non-programmers) because all they needed to do was download the plugin and upload it to their website. No coding necessary.
Through the subsequent years, features continued to be poured in steadily, making the goal of allowing everyone to run their own blog more attainable. Notable features included:

- translations

- “what-you-see-is-what-you-get” (WYSIWYG) editor

- one-click updates for WordPress, allowing non-developers to update WordPress

- themes, which allowed non-developers to give their site a fresh new look in a few clicks

- pages and custom post types, which allowed WordPress to manage any type of content, not just a blog

Making WordPress usable by everyone often had its drawbacks. Much of the old code from 15 years ago is still there because removing it could break some websites, or changing the code might make it harder to read for novice programmers. But overall, it has succeeded in making publishing, and running a website, something attainable to everyday users.

Free… but Who Pays the Bills?

While WordPress grew in popularity, so did the required time commitment. And an often-overlooked reality of free software is that, while there are many who contribute to it gladly without pay, they still need money to survive. Many, many software projects are used globally by millions and yet are maintained by only a handful of overworked people.
WordPress required more time than Matt and his fellow volunteer contributors could afford. One of WordPress’ early saviours was CNET. CNET used WordPress for several of its blogs, and so wanted to see it progress. They offered to pay Matt to maintain it so he could do it full time. So Matt quit college and began working on WordPress full time as CNET employee. But importantly, CNET hadn’t bought WordPress: the software was still free, it’s just that now there was someone to pay for its improvement, which wasn’t free.

Investing in Free Software

While Matt was in a coveted situation, being paid to work on his hobby, he saw more opportunity. While WordPress continued to “Democratize Publishing”, he was becoming more aware of some persistent problems that were really difficult to solve. The two biggest ones were: spam, and self-hosting a website. WordPress websites were getting hammered by spam comments, and hosting their own websites was still too difficult for many users. And to top it all off, just having one dedicated developer severly hampered how far WordPress could progress.
Matt then did a fairly amazing thing: somehow, he convinced a few angel investors to back his creation of a company, Automattic, focused on developing WordPress, free software. How did Matt plan to make a return on investment when WordPress was, and forever would be, free? Or how did he convince investors of his plan? This might have been a miracle.
It seems Automattic’s business model was to fuel the WordPress community, and support it with some related, optional, upgrades. For example, Automattic created a plugin called Akismet, which helps reduce spam. They also created a website called WordPress.com, which was a “hosted” way to run WordPress- meaning a way for someone to use WordPress to blog, but not need to setup and maintain their own server. Both of these were separate services which Automattic could charge money for, so it didn’t make WordPress less free at all.
Automattic managed to secure two more rounds of venture capital, and now has a team of over 500. And although Automattic is turning a profit on WordPress users, no WordPress user is obliged to use any of their services. I, after 7 years of using WordPress, still haven’t given them a dollar. WordPress is just as free as it ever was, but there are paid options for those who want them, and a well-funded company supporting WordPress’ growth.

A Community, Not Users

In the proprietary world, [people who use software] are typically called “users,” a strange term that connotes dependence and addiction. In the open source world, they’re more rightly called a community.
– https://ma.tt/2014/01/four-freedoms/

Very early on, WordPress sought to build a diverse, welcoming community. And as hard as it may have been to build a business model around free software, I think creating a culture is even more difficult. WordPress has a great culture, in contrast to many environments. Often, “techies” consider themselves superior to “non-techies” because they know the jargon and technical details of software, but then “non-techies” are annoyed at “techies”‘ arrogance and social ineptitude. While these problems still exist in the WordPress community, somehow there is a lot more understanding. Being a stereotypical white, male programmer is not a requirement to participate in the WordPress community.
The earliest WordPress meetup was in January 2004, and more popped up everywhere. These were opportunities to share knowledge, and for often-isolated community members to gather and socialize.
The first WordCamp (WordPress conference) was in July 2005, and since WordCamps have spread and been organized in the hundreds all over the globe. And they usually cost $20. This allows for nearly all the WordPress community to participate in a conference. This is in stark contrast to most other software conferences, where there is usually only one held globally each year, costing thousands of dollars. And then with the introduction of WordPress TV, anyone could digitally sit in on conference sessions. All this community building helped create dedication to the software that went beyond just technical help.
The WordPress Slack channel, Support Forum, and Trac system also allow anyone to participate in helping WordPress become better, and create a reputation for themselves in the process.
There have been hundreds of people who have contributed code to the various releases of WordPress, some as employees of companies and some as freelancers or hobbyists. But the lion share is still done by WordPress’ biggest supporter: Automattic. It is really a remarkable balance between Automattic and the WordPress, the free software.
The WordPress Foundation was founded in 2009. It is a non-profit organization, like Mozilla and The Free Software Foundation, whose purpose is to encourage the support of WordPress: the software, its community, and its trademark. The trademark was actually registered by Automattic early on (hence why they own wordpress.com) but Matt pushed for it to be donated to the newly-founded organization. His reasoning was:

Automattic might not always be under my influence, so from the beginning I envisioned a structure where for-profit, non-profit, and not-just-for-profit could coexist and balance each other out. It’s important for me to know that WordPress will be protected and that the brand will continue to be a beacon of open source freedom regardless of whether any company is as benevolent as Automattic has been thus far.
– https://ma.tt/2010/09/wordpress-trademark/

Perhaps this was Matt’s old naive spirit of software freedom, or maybe an investment in the ecosystem his company needed to survive. But regardless, it was another significant step in helping to assure WordPress will survive for longer than one company’s financial interest in it.

Feedback Loop

And now with such a solid base of software freedom, large and global community, and even venture capital backing, WordPress has ignited a explosion in popularity which seems to feed on itself. The feedback loop goes something like this:

- more users, leads to

- more plugins, themes, hosts and web agencies specializing in WordPress, which leads to

- more brand awareness and trust, which leads to

- more users, etc.

In other words, WordPress is popular because it’s ubiquitous… which is really a fancy way of saying “it’s popular because it’s popular.”
In my case, the company I work for, Event Espresso, continues to specialize in making event registration plugins for WordPress because it is a big market. But in turn, through our hosted solution, EventSmart, we’ve introduced a lot of people to WordPress.

A Caution

It seems to me that WordPress’ early success was due to its being free software. Afterwards, its mission to democratize publishing guided its development so it appealed to a very wide range of users, and venture capital funding helped keep it alive and improving. But now WordPress’ success is a self-feedback loop which could also be described as a bubble… and someday that bubble may burst.
For example, many WordPress users don’t know what free software is. They may be easily enticed by restrictive, but easier-to-use, software. Then someday further down the road, we’ll have a repeat of the Movable Type situation, where they’ll suddenly become aware that proprietary software is a sandy foundation for a business.
I think the WordPress community needs to hold more dearly to the freedom of the GPL, and internalize the mission to democratize publishing.

Celebrate the Successes

To me, WordPress’ story is inspiring. The ideals of freedom and inclusion won out over restriction and exclusivity. Sure, people have taken advantage of WordPress’ freedom and trust, but they haven’t destroyed it. How has WordPress survived the years of naysayers, hackers, and GPL abusers? Matt said this:

Though the freedom intrinsic in the GPL has allowed people to abuse WordPress it has allowed even more people to do amazing things and over time the good far, far outweighs the bad…
how do you maximize the effect of the good[?]
Celebrate the successes.
Talk, connect, promote, and embrace the people who are creating things on top of your creation.
Provide a way for people to choose to help you, and try to remove as much friction from that process as possible.
[People will] want to give something back.
– https://ma.tt/2007/07/price-of-freedom/

Maybe that’s idealistic and naive, and maybe it wouldn’t work in the real world. One might think endeavors like that would never survive.
Then again, 15 years and 30% of the Internet indicate it has worked pretty well so far.

- A history of WordPress

- Another history of WordPress

- Quota question on “Why WordPress is so popular”

- How WordPress became so popular

- PBS video on WordPress and Automattic (although it’s a bit dated)

- The difference between the WordPress Foundation and Automattic

- WordPress user survey

- Matt mailed his car keys to strangers online (before WordPress)

How Can We Get More Non-English Speakers Contributing to WordPress?

https://cmljnelson.blog/2018/06/28/how-can-we-get-more-non-english-speakers-contributing-to-wordpress/ June 28, 2018

3 minute read
There are more WordPress users who are non-English speakers, yet nearly all code contributors to WordPress are fluent in English. That sounds problematic to me. Why is that, and can anything be done to fix this situation?

Huge Potential in Non-English-Speaking Contributors

There is an interesting inconstancy in the WordPress community:

1. from my observations, most WordPress core contributors in Slack and Trac are very proficient in English (either they’re native English speakers or their English is so good they may as well be)

2. according to surveys, most users of WordPress are from countries where English is not their first language.

It seems to me that English-speaking countries are disproportionately over-represented among WordPress contributors. If there are more non-English users, why aren’t there more non-English contributors? Why are English speakers more likely to contribute and non-English speakers more likely to just consume?
This represents a major mis-alignment. English speakers are making decisions about software used primarily by non-English speakers- a minority making decisions for the majority has always led to trouble (think of basically any national revolution).
I think WordPress has grown so much in non-English speaking countries because of its efforts to democratize publishing– anyone, even non-English speakers, should be able to setup, use, and modify WordPress. And it seems to be pretty successful at that. But if those non-English speakers contributed to WordPress proportionately as much as they used it, not only would their needs be met, but we’d double the number of contributors.

Why is Contributing to WordPress Core so Hard for Non-English Speakers?

For starters, because the code and all the communications are in English only. (Whereas interface and documentation are well translated.) As an English speaking developer, a few times I’ve had to deal with documentation and code written in another language and it’s a pain. At Event Espresso, I’ve advocated doubling the cost for such work because of the trouble working in another language.
But for WordPress it’s not just a matter of contributors needing to run everything through google translate. Contributing to software in a foreign language isn’t like just using software written in a foreign language. Here’s the additional difficulties I see:

1. There are lots of technical and slang terms in use (eg PHP and IMO), many of which you don’t find in a translation dictionary or Google Translate

2. When contributing to code, you’re often explaining half-developed, abstract ideas (I have enough trouble with that with my team and we’re all fluent English speakers). What’s more, you not only need to explain an idea to others, you need to convince them your solution is the best and worth the effort. That takes a lot of well-placed words.

3. Native English speakers use lots of filler words, often to be polite. Eg a fluent English speaker might say “if you don’t mind, go ahead and implement the fix at your leisure”, whereas a non-fluent English speaker might just say “fix it.” This means non-fluent English speakers both have trouble understanding others, even when they’re fairly good at English, and come off as rude to others.

4. Besides just talking about software, a big part of contributing to code is convincing others that they’re not wasting their time with you- that you’ll give more than you take and be won’t be a jerk. When your English is only good enough to convey information, but not build rapport, you’ll often get brushed off as a nuisance.

5. Lastly, there are lots of unspoken rules about contributing to open source, many of which I’m still learning after being involved in it for over 5 years. For example, I recently heard if you want to help in an upcoming release of WordPress, you really ought to be involved from the planning stage. If you appear online with suggestions a few days before the first beta release, your suggestions are too late to actually help, and so your contributions won’t be as well-received.

So What can be Done?

I think excellent work is being done to make WordPress usable by non-fluent English speakers, as the results show. But facilitating them contributing in an English-only environment is hard. Here’s some ideas:

1. Give them the benefit of the doubt. When they say “give me reply”, mentally insert the formal filler words like “please give me a reply when you can”

2. Be patient. They might need to explain their ideas twice, as might you.

3. Be straightforward. Explain your ideas simply and succinctly, avoiding slang terms. This is probably a good idea anyway, as it takes great mastery of a subject to explain it simply.

Those are my ideas anyway. Pretty unsatisfactory, I know. I’ve been a non-native speaker a few times, but rarely a non-native speaking developer. I don’t have the answers to the problem, but I do think we should start by acknowledging there is a problem– or at least, that there’s an opportunity. We need more non-fluent English speaking contributors.
What do you think can be done to help get more non-English contributors involved in WordPress?

Penpals Explanation of PHP/cURL/openSSL/TLS/SSL/PayPal Handshake Issues

https://cmljnelson.blog/2018/07/16/penpals-explantion-of-php-curl-openssl-tls-ssl-handshake-connectivity-issues/ July 16, 2018

5 minute read
Today I spent a few hours wrapping my head around an issue where some websites weren’t able to connect properly to PayPal.com. I found it pretty tricky to understand because it involved quite a few technologies and programs:

- PHP: a programming language, and a program to interpret lines of code written in that programming language (aka interpreter)

- cURL: a program for composing messages to be sent over the Internet

- openSSL: a program for encrypting messages according to one of many encryption algorithms

- TLS (sometimes the same thing as SSL): a protocol for encrypting HTTP messages so they can be securely sent between two servers

- PayPal: a separate server that handles payment processing, which just recently started requiring all communication with its servers be over the protocol TLS 1.2

And each of those programs has various versions, some which don’t play nicely with each other.
I like making analogies to the real world in order to better understand computer stuff. So here we go:

School Penpals Analogy

Imagine a gradeschool penpals initiative. Principal Helen Powers tells 5th grade teacher, Mr. Curls, to have the kids write letters off to another school somewhere else in the world. Mr Curls tells one of his students, Open-mouthed Susie-Lee Lewinski, to write a letter to another child on the other side of the planet. Here’s their pictures, in case you were wondering:

Link of the removed image [Image removed]

Principal Helen Powers

Link of the removed image [Image removed]

Mr Curls

Link of the removed image [Image removed]

Open-mouthed Susie-Lee Lewinski

Except we don’t know what language the other child speaks (in fact, they haven’t decided where to send the letter yet). So the first letter Susie should send will find out what language the other child speaks, and if Susie can also write in that language (by the way, Susie is a polyglot: she speaks Arabic, Greek, Latin, Spanish, Esperanto and English).
So when everything goes smoothly:

1. Principal Helen Powers asks Mr Curls to send a message to a given address

2. Mr Curls tells Susie to compose a message to the unknown child

3. Susie’s first letter is a “handshake” letter, briefly telling the other child what languages she speaks, and asking them which one they’d like to use.

4. The other child, we’ll call them Palay, responds saying they’d like to speak in Esperanto

5. Susie and Palay continue to correspond in Esperanto

PHP, cURL, OpenSSL, and TLS Working Properly with PayPal

What each character represents:

- Principal Helen Powers: PHP interpreter

- Mr Curls: cURL

- Open-Mouthed Susie-Lee Lewinski: OpenSSL

- various versions of TLS and SSL: different languages Susie can speak

- Palay : PayPal

When everything works smoothly,

1. PHP code has instructions to use cURL to send a request to PayPal (like Principal Powers instructing Mr Curls to send a message to Palay)

2. cURL takes those instructions and, in turn, instructs openSSL to send a request to PayPal

3. openSSL sends a handshake request to PayPal, telling its server what versions of TLS and SSL it can handle

4. PayPal’s server responds with what versions of TLS and SSL it can handle

5. a version of TLS or SSL is chosen (or “negotiated”), and subsequent messages are sent and received using that protocol

Problems in Communication

There are a few problems that can occur both between clients and servers communicating over the Internet, and between grade school penpals.

The Children Speak Different Languages

Or, the servers don’t have a shared supported version of TLS or SSL. In the case with PayPal, for security, they decided their server would only communicating using TLS version 1.2 or higher (and no version of SSL). This is fine for most websites on servers which have had openSSL updated in the last 5 years or so (specifically, servers should at least use openSSL version 1.0.1c/). However, if openSSL is too old, it won’t know how to communicate in TLS 1.2, and so PayPal will reply with an error like this:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

The Principal Insists Susie Speaks in a Language the Other Child Doesn’t Know

Or, the PHP code specifies a specific version of TLS or SSL must be used, but the other server refuses to use that version.
Eg, in PHP code you can set curl_setopt ( $handle, CURLOPT_SSLVERSION, CURL_SSLVERSION_SSLv2) that will tell cURL to tell openSSL to only communicate using SSL version 2, not any other version of SSL or TLS. That’s fine if the other server is willing to communicate in SSLv2, but if they aren’t, like in the case of PayPal, they’ll respond with another error message.

Miscommunication between Mr Curls and Susie

Or, there is a bug in the version of cURL or openSSL in use, which causes openSSL to not auto-negotiate the best version of TLS or SSL to communicate with (the best usually being the most recent version of TLS they both support, or failing that, the most recent version of SSL they both support).
cURL version 7.29 had a problem that it supports TLS 1.2, but it needs to specifically told to use it instead of an different version of SSL or TLS. (This is like unless you tell Mr Curls that it’s ok for Susie to communicate in English, he’ll tell her it’s not ok.) According to this WordPress Trac ticket, the problem could be solved by specifically instructing cURL to use TLS 1.0 or higher (as of 2015, 99% of servers supported it) by using curl_setopt ( $handle, CURLOPT_SSLVERSION,        efefefefefefefef);.
Also, cURL version 7.24 with openSSl 1.0.1e appears to have a different bug: if you added the above-mentioned line telling cURL to use TLS version 1 or higher, curl_setopt ( $handle, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1 );, openSSL wouldn’t communicate in TLS 1.2. (This is like Principal Powers telling Mr Curls “Susie is allowed to communicate in Spanish, Esperanto, or English” but Mr Curls misheard and missed the last two languages mentioned, and so thought Susie should only be allowed to communicate in Spanish). Ironically, if the PHP code doesn’t specify any SSL or TLS version (or specifies TLS 1.2), openSSL is able to auto-negotiate the best version of TLS to use.

The Dilemma We Faced

In section “Miscommunications with Mr Curls”, you see that for cURL 7.29 we should add curl_setopt ( $handle, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1 ); to fix handshake issues, but for cURL 7.24 with openSSL 1.0.1e that actually creates issues. So what’s the best general approach (that works for most version of cURL)?
It was suggested you should just check which version of openSSL is in use, and if it’s a version that know how to use TLS 1.2, the PHP code should tell cURL to use that. But if not, the PHP code should tell cURL to just use the latest version of TLS possible.
But then, it was realized that the version of openSSL that PHP knows about may be different than the version of openSSL cURL is using, so it’s impossible for PHP to determine which version of openSSL cURL is using. Also, we’d still have the second “Miscommunication between Mr Curls and Susie”.
An important point though: for our current purposes, it’s mainly communication with PayPal that was causing us grief.

The Solution We Went With

So, our PHP code now specifically instructs requests going to PayPal to only use TLS1.2. Like so: curl_setop($handle, CURLOPT_SSLVERSION, 6);  (note that 6 is the value of CURL_SSLVERSION_TLSv1_2, but it’s nice to use its value in case the constant isn’t defined). If the version of openSSL in-use on the server doesn’t know how to use TLS 1.2, the communication will fail. But it’s doomed anyway: it doesn’t know how to communicate with TLS 1.2 and PayPal won’t accept anything else. So the PHP code explicitly tells cURL: use TLS 1.2 or bust.
But, requests going to other servers, which might not yet support TLS 1.2, can fallback to openSSL’s normal TLS/SSL-version auto-negotiation, which get it right 99% of the time.
What’s more, we saw the most popular e-Commerce WordPress plugin, WooCommerce, is doing exactly that too. So we’ll be in pretty good company anyway.

See a Problem?

Do you see a problem in my logic? Or any parts that don’t make very much sense? Please let me know in the comments!

My Takeaways from "Gutenberg for Plugin Owners" Crowdcast

https://cmljnelson.blog/2018/07/18/my-takeaways-from-gutenberg-for-plugin-owners-crowdcast/ July 18, 2018

2 minute read
Today I watched “Gutenberg for Plugin Owners“, an online discussion between Brian Hogg, Kyle Maurer, and Daniel Bachhuber, where they discussed and answered questions about how WordPress plugin owners can better prepare for the new editor, Gutenberg.
You can watch the replay, but here’s my notes. I was admittedly doing some somewhat noisy house-chores while listening to it (scrubbing a deck) so this is only my highlights, not an overview.

- Inline shortcodes (that is shortcodes that, when rendered, only take up a word or two of text, not the full width of the page) may still have a place in Gutenberg. Most shortcodes are meant to take up most of the page’s width (eg a gallery shortcode, a buy-product shortcode, or Event Espresso’s [ESPRESSO_CHECKOUT] shortcode), and those should ideally be changed into Gutenberg blocks (because blocks will be easier for users than remembering shortcodes).

- In order to make simple Gutenberg blocks, you might not need to learn any React. In fact, Daniel gave some code samples showing how to create simple Gutenberg blocks that require almost no javascript code.

- On that note, Daniel pointed out it’s preferable to declare blocks in PHP code rather than Javascript, because “PHP can be a source of truth for Javascript, but Javascript can’t be a source of truth for PHP”. Eg, the REST API can be aware of Gutenberg blocks declared in PHP, but not blocks declared in Javascript

- In online collaboration, if you jump into a conversation just saying “this sux”, you’ll basically be treated as a troll. You need to explain why you think it sucks, and how you would improve it (oh, and make sure you’ve read up on all the previous discussion on the topic, otherwise you’ll likely bring up something that’s already been considered, or overlook some problem already identified)

- On that topic, Daniel recommended a book (can’t find where he mentioned it! if someone knows plz tweet me or comment below) about collaboration. He mentioned it should be established what roles everyone has in an online discussion: who’s a “teacher”, “peer” or “student”. Otherwise you’re stuck with a democracy or a meritocracy, the former is mob rule and the latter is very slow and requires so many compromises it often ends on a decision no one really likes.

- Just trying out Gutenberg can actually be risky for a site owner, because Gutenberg changes post content to fit its data structure. That process isn’t perfect yet, errors can happen which can cause data loss (or, most likely, page layout issues). These error can normally be fixed easily if the site has post revisions working normally. But if they’ve specifically disabled post revisions, the changes could be painful to undo. So, it’s best to try Gutenberg only if you have post revisions activated.

Again, I missed quite a bit, so there was a lot more covered, but those were my take-aways.
Here’s the link to it again: Gutenberg for Plugin Owners

Which Way Do Your Slashes Face in PHP?

https://cmljnelson.blog/2018/07/26/which-way-do-your-slashes-face/ July 26, 2018

4 minute read
When writing out filepaths and URLs, should you use forward slashes / or backslashes \? Windows expects one, whereas Unix-style operating systems (Linux and Mac OSs, primarily) expect another. PHP has two built-in solutions, but both have problems, especially if you’re working with WordPress.

Backstory

At work, I’ve recently had some trouble getting my linux virtual machine VVV to work and so have been trying out a different system that runs my development websites directly on my Windows operating system, Laragon.
It’s been quite a while since any of us at Event Espresso have ran our code on a Windows machine directly, so there were a few problems, chiefly that Windows uses backslashes, \, to separate folders, whereas Unix-style operating systems use forward slashes, /.
This meant that some unit test code expected to find forward slashes, and when it found backslashes, reported an error.
This forward-or-backslashes problem occurs a little when you’re writing code that will only ever run on one machine. But the problem gets worse if the code will be distributed and could be run anywhere. Plus, if you’re writing code that works with WordPress, there are a few more considerations.

Which Operating System Uses Which Again?

So, on Windows machines, the path to a file will look something like this: path\to\file.php, whereas on Unix-style operating systems (even if they’re a virtual machine, like VVV), the paths instead look like path/to/file.php.

PHP’s Rescue Attempts

This isn’t a new problem, by any means, and the programming language PHP has given us two different attempts to fix it, but each has problems. Let me tell what the options are, then their problems.

Directory Separator Constant

There is a constant called DIRECTORY_SEPARATOR, which is / on Unix-style operating systems, and it’s \ on Windows machines. (I suppose a Windows 10 machine using the Linux subsystem  will emulate Linux and so use /).
So, theoretically, your PHP code can just use DIRECTORY_SEPARATOR in paths, and you’ll be ok. Eg instead of path\to\file.php, you would do 'path' . DIRECTORY_SEPARATOR . 'to' . DIRECTORY_SEPARATOR . 'file.php'. But there’s another option…

PHP Always Accepts Forward Slashes

Also, importantly, when writing PHP code, you can always use forward slashes in paths, even for code that runs on a Windows machine. So, no need to use the DIRECTORY_SEPARATOR constant anyways. Just always use forward slashes, like your paths are all for Unix-style operating systems. Eg just always do path/to/file.php. Couldn’t be easier, right? Actually, you may be surprised, this Kaiju isn’t quite dead yet…

Both Have Problems

If you use either DIRECTORY_SEPARATOR or always use forward slashes, there are a few problems and mistakes you can make. Meaning neither one is perfect.

Problems Using Directory Separator Constant

1. Obviously it’s a lot more typing path . DIRECTORY_SEPARATOR . 'to' . DIRECTORY_SEPARATOR . 'file.php' is way longer than path/to/file.php. Not only does this actually get exhausting, it’s pretty easy to mistype and add a bug.

2. You need to remember that the directory separator in filepaths on a computer/server differ depending on the operating system, but paths in URLs to webpages, no matter which operating systems are in use, should use /. So, when writing out a path, you’ll always need to ask yourself “Is this a filepath on the computer running the code? Or is this a path that will go into a URL pointing to another website?” It’s easy to get mixed up.

3. If you do use DIRECTORY_SEPARATOR in a URL, and that URL is passed into WordPress’ functions esc_url(), wp_enqueue_script or wp_enqueue_style, it will remove the backslash and so breaks the URL. (Note for completeness: web browsers are, of themselves, pretty forgiving – if you give them the wrong slash, they’ll fix it automatically for you. But that doesn’t help if WordPress has already removed the slash entirely).

4. WordPress core mostly doesn’t use DIRECTORY_SEPARATOR, it always uses forward slash /. This means, if your code is running as a WordPress plugin (like ours) or a theme, even though your code uses DIRECTORY_SEPARATOR, WordPress’ probably won’t, and so paths will still use a mix of forward and backslashes. This can be onerous because your code and unit tests need to expect either type of slash.

So if your code isn’t working with WordPress, using DIRECTORY_SEPARATOR is just more typing and you need to know if the path is part of a directory path or a URL. Otherwise, it’s good because filepaths always use DIRECTORY_SEPARATOR, which is nice and predictable.

Problems Using Forward Slashes Only

1. On Windows machines, PHP’s built-in functions and constants use \. Eg using __FILE__ from within a file will always return path\to\file.php, regardless of which slashes you decide to type into your code. That means no matter how much you try to “just always use forward slashes”, PHP has already foiled your plans: paths in your code will still be a mix of forward and backslashes. This inconsistency gets a bit sore on the eyes.

2. Just like problem #4 with using the DIRECTORY_SEPARATOR, your code needs to expect both types of slashes in filepaths. That’s again onerous in unit tests and parsing filepaths.

So the list of problems using forward slashes is shorter, at least if you’re using WordPress.

So, use Directory Separator Constant, or Forward Slash?

If your using WordPress,  you’re probably best always using forward slashes. It’s consistent with WordPress, easier to type, and doesn’t require asking yourself “is this part of a filepath or a URL?”; your code will just need to realize PHP’s built-in functions use DIRECTORY_SEPARATOR, whereas WordPress’ functions use /, so your code needs to expect both types of slashes will be used as directory separators. That’s pretty easy to deal with. Just do str_replace('\\', '/', $filepath);.
Update: In WordPress, it’s actually even easier: do wp_normalize_path(), like documented on developer.wordpress.org. Although, if you’re writing code for a distributed plugin or theme, you should always be using it, regardless of whether you yourself are on a Windows machine. Thanks @wpscholar for the tip!
If you’re not using WordPress, (or my WordPress trac ticket to use DIRECTORY_SEPARATOR gets accepted) I’d use DIRECTORY_SEPARATOR.  You’ll be able to rely on filepaths always using the operating system’s slash-of-choice in unit tests and filepath parsing. If your fingers get tired of typing it out, you can create your own constant like DS as a short-hand for it.
Did I get it right? Does it not make sense? Please leave a comment.

How to Migrate from a Self-Hosted WordPress Site to WordPress.com

https://cmljnelson.blog/2018/08/11/migrating-from-self-hosted-site-to-wordpress-com/ August 11, 2018

13 minute read
If you’ve tried self-hosting WordPress, but found it a struggle, and are ready to try WordPress.com instead, this is for you. Notice I said “try”– you can start off by just trying WordPress.com, and if it meets your needs, you can finish the move.
This is the overview of what you’ll need to do:

1. Setup a site on wordpress.com

2. Export content from the old site

3. Import content into the new WordPress.com Site

4. Point folks to your new site

These are basically the same steps as WordPress.com explains in their short tutorial. Except their tutorial misses a few things: yes it will bring your posts into the new site, but it skips some important details.
So without further ado…

You don’t need to rack your brain wondering if WordPress.com will serve all your needs. Just create a free site there, and try it out. Then you’ll know if you should follow through with the rest of the steps.
But before you go off and do that, an important note:
If your old site uses the JetPack plugin, first sign into WordPress.com using the same account as you used for JetPack.
(If you’re not sure if your old site used the JetPack plugin, sign into your old site, click “Plugins” and look for it, and if it says it’s “Active”. If it’s not there, or it doesn’t say “Active”, then you don’t have it activated.)
If you do have JetPack activated, follow the instructions under 1.1 Create a Site with your Existing JetPack Account. If not, skip that, and instead follow the instructions under 1.2 Create a New Account and Site on WordPress.com.

1.1 Create a Site with your Existing JetPack Account

If you want to move your subscribers over from your old site to the new one, it’s important they both be on the same account (here’s why). So here’s what to do:

[Image removed]

Go to wordpress.com and click “Sign In”

[Image removed]

After you’ve signed in, click “My Site”

[Image removed]

Then click “Add New Site”

[Image removed]

Click “Start Now”

Great, you’ve started making your site. Go to Section 1.3 Setup New WordPress Site.
1.2 Create a New Account and Site on WordPress.com

If your old site didn’t have JetPack on it, then just start creating a new site on wordpress.com and create a new account. Here’s what to do:

[Image removed]

Go to wordpress.com and click “Get Started”

Then, continue below…
1.3 Setup New WordPress Site

These steps are the same regardless of whether you had a JetPack account or not.

[Image removed]

Fill in the questionnaire

Now comes choosing a domain. If you think you want to move your old site to wordpress.com, even if you do own the domain already, I would suggest you should initially select the free wordpress.com domain. Why? This way your old site will continue to be alive and well, meanwhile, you can play and tinker on the new site before any visitors arrive at it. Transferring the domain (which is when site visitors will start going to your new site) is actually the last step we want to do, and we’ll get there. But for now, we want to try out wordpress.com and set the site up.

[Image removed]

Enter a temporary domain, and choose the free “wordpress.com” option for now. We can switch to a prettier domain once we’ve got it all set up how we want.

[Image removed]

Choose your plan. If you want to have a custom domain though (ie, not have your site end in “wordpress.com”, you’ll at least need the Personal plan)

If you didn’t already have an account, they’ll ask you to create it on the last step. And from here, you can play with using wordpress.com.
You now have a wordpress.com site. Time to figure out if you like it, and if it will meet your needs! I suggest:

- If you want to stick with your old theme, search to see if it’s available on wordpress.com (it might be a premium theme, require having a Premium plan, or it might not exist on wordpress.com, in which case you’ll need to buy the Business plan and upload it). Alternatively, you’re free to experiment with new themes.

- Try writing an experimental post. The post-writing interface is different on wordpress.com (it’s code name is “Calypso”, if you care to know). It is meant to be more streamlined, but it’s different. Make sure you’re happy with it. After you’ve written this post, feel free to trash it.

- Most importantly, you have no plugins on wordpress.com (unless you’re on the Business license), which means there might be some things you could do on your old site that you can’t do on wordpress.com. Eg, maybe you could sell products, or view Google Analytics. Well, wordpress.com has quite a few options, but they’re certainly not the same or as flexible. Make sure you can do all the important things you used to do on your old site.

- Also, if your old site’s plugins stored data, that data might not migrate to wordpress.com. Eg., even if you purchase the Business license and upload the plugin onto wordpress.com, there still might be data stuck on your old site.

- If you have lots of media (eg images, videos, and audio files) on your old site, you may want to double-check wordpress.com will have enough space for them. On your old site, you can install the “My Simple Space” plugin, then go to your Dashboard page. You’ll see the “My Simple Space” widget. The important number is the one next to “uploads”. If it’s more than 3GB, you’ll need to have a paid plan. See the storage limits on the wordpress.com plans here.

But don’t worry about moving all your old posts and pages over. We’ll do that next. For now, just play around with it and verify it meets your needs.

2. Export Content from the Old Site

This is where your old self-hosted WordPress site will export all its old posts, pages, comments, and media into a file you can upload to wordpress.com.
This is really easy if you plan on using the same domain for your wordpress.com site as you used to use on your self-hosted site (eg, your old domain was “kitchengadgets.com”, and after you’ve got your new wordpress.com website all setup, it will be the new “kitchengadgets.com”). If so, skip ahead to generating the export file.
But if your wordpress.com site is going to have a different domain (eg, your old domain was “kitchengadgets.com” but you’ll be using a new custom domain called “kitchenstuff.com” or you’ll permanently stick with “kitchengadgets.wordpress.com”), you should update all the links in your posts before you export your data.

2.1 Updating Links to Your New Domain

In your current site, you probably have images, and links to other pages and posts on your website right? Well, if your new wordpress.com site is going to have a different domain, all those links will still point to your old website, which I doubt you want. You want to keep people on your new site, especially if you will shut down your old site.
Changing all the image URLs and links one-by-one is tedious, so here’s how to do is all at once: use the “Better Search and Replace” plugin.
Before doing this, it’s probably a good idea to make a database backup of your old site, just in case something goes haywire. (Don’t worry, this is probably the last time you’ll do it, wordpress.com will take care of that once you’ve moved over.) Here’s a good explanation of how to do that.
After you’ve created a backup, here’s how to update the links…

[Image removed]

Log into your OLD site, go to the plugins page, and click “Add New”

[Image removed]

Search for “Better Search Replace”. Click “Install Now” next to it, then “Activate”.

[Image removed]

Once activated, click on “Tools”, then “Better Search Replace”

[Image removed]

In “Search for”, enter your old domain, eg “kitchengadgets.com” (no “http” or anything); in “Replace with” enter your new domain, eg “kitchengadgets.wordpress.com”, and then just select the “wp_posts” table to only update your posts, pages, and media. (You could also select “wp_comments” if you want to update links in comments.) You might want to do a “dry run” first (ie, where nothing in your database is actually changed, it just analyzes your data and says what will happen during a normal run).

Visit a post or page that had a link on it. The link should now send you to your new site (although we haven’t yet brought all the posts and pages into the new site, so that particular page might not yet be setup; that’s fine, be patient.)2.1
2.2 Export Posts, Pages, Media and Comments From Your Old Site

This is where we download the posts, media, and comments from your old self-hosted site into a file, which we’ll later upload to wordpress.com

[Image removed]

Log into your old site, and click “Tools”, then “Export”

[Image removed]

Then just click “Download Export File”, and save it somewhere you can find it in a few seconds.

Link of the removed image [Image removed]

Once the export file is generated and downloaded, your web browser may ask you if you want to open it, or save it.
JUST SAVE IT. (Your computer won’t know how to open it and will give you errors if you try.)

Ok, now you’ve got the export file. Continue…
3. Import Content Into Your New WordPress.com Site

This is where your new wordpress.com site will get all the blog posts, pages, media, and comments from your old self-hosted site.
Before importing, you probably want to temporarily disable sending pingbacks. Otherwise, WordPress will treat each imported blog post as a new blog post, and send pingbacks for them all. This is probably not what you want (you probably already sent pingbacks for all of them).

Link of the removed image [Image removed]

Log into your WordPress.com site, then go to “Settings”, then “Discussion”. Make sure “Attempt to notify any blogs linked to from the article” is UNchecked.
Once the import is finished, you might want to turn this back on, but it’s almost certainly not what you want when importing your old posts to the new site.

[Image removed]

Click “Import”, then find the row saying “WordPress” and click “Start Import”

[Image removed]

Drag and Drop the export file (from “2.2 Export Posts, Pages, Media and Comments From Your Old Site”) over the upload area, and then click “Continue”

[Image removed]

It will ask you which user you want to be the author of these posts. Chances are it’s just you, so that’s a pretty easy choice. Then click “Start Import”

[Image removed]

Wait patiently. Like they said, you can go away, they’ll notify you when the import is done.

Once they notify you that the import is complete, double-check your blog posts, pages, media, and comments are all there and work ok. It’s probably good to view some of them from the front-end of your website (easiest way to do that is to just enter your domain into your browser’s address bar).
At this point, you may also need to update your site’s menu (click “Customize” then “Menus”) to have it look like it did on your old site.
If something doesn’t look right, ask wordpress.com support what’s wrong (or use the forums, someone will likely respond in a day). Try your best to describe

- what you wanted to happen

- what you did

- what, when, and where you see a problem

Barring any trouble, at this point your new wordpress.com site should work as you want. If you’re happy with it, it’s time to move your domain over to wordpress.com, and your subscribers too…

4. Point Folks to Your New Site

Up until this point, your old self-hosted site is still the one everyone is using. This is the step where you fully commit to using WordPress.com for your new site.
If you want your new wordpress.com site to use the same domain as your old self-hosted site (eg, if your old self-hosted site was “kitchengadgets.com” and you now want “kitchengadgets.com” to be your wordpress.com site), you’re going to need to either “transfer your domain” or “map your domain”. (But if you’re happy with your wordpress.com site’s current domain, skip ahead to 4.2 Migrate Old Subscribers).

4.1 Transferring/Mapping Your Domain to WordPress.com

This will make it so when readers enter your old website address (eg “kitchengadgets.com”) they’ll be sent to your new wordpress.com site instead of your old self-hosted site.
WordPress.com already has a good explanation of how to do this here. They’re pretty thorough though, and so it got pretty big. So how about I walk you through it?

[Image removed]

When logged into wordpress.com, click “Domains” on the left menu, then “Add Domain” in the top-right

[Image removed]

Enter your old self-hosted website’s domain.

[Image removed]

Click “Use a Domain I Own”

Now time for you to decide something: do you want to transfer the domain, or map it.

- Transferring the domain means that, from now on, you’ll pay wordpress.com for domain registration (eg, owning the domain “kitchengadgets.com”). WordPress.com will become your domain registrar.

- Mapping the domain means you will continue to pay your old hosting company (or domain registrar) for domain registration.

Which should you choose? I suggest you probably want to just transfer it. Here’s why:

- transferring will be simpler in the long run, as you’ll just be dealing with WordPress.com for your website and managing your domain

- although WordPress.com slightly overcharges for domain registration (like $10 a year), they also ding you with $18 surcharge if you just map the domain. So it’s usually cheaper to just transfer your domain.

[Image removed]

You probably want to choose “Transfer Domain to WordPress.com”, but it’s up to you. Click either “Transfer to WordPress.com” or “Buy Domain Mapping”.

Assuming you chose to Transfer your Domain, you’ll next need to unlock your domain and get the authorization code (a.k.a. EPP code), so wordpress.com can migrate your domain over to them.
The steps to do this vary by hosting company. WordPress.com keeps a list of the most common hosts, with links to their instructions for unlocking a domain and transferring the domain to a new domain registrar, here: Transferring a domain you already own to WordPress.com »Preparing a domain registered elsewhere for transfer to WordPress.com.
Here’s how I unlocked the domain with BlueHost:

[Image removed]

If you’re on BlueHost, go to bluehost.com and log in (“hosting” log in, if you were wondering which). Click “domains” at the top.

[Image removed]

Click the domain you want to transfer to WordPress.com

[Image removed]

See where it says “Locked”? Click “edit” right next to it.

[Image removed]

Then “Unlock Your Domain”.

Your domain is now unlocked. Now to just get the authorization code (aka EPP code) so you can pass it onto WordPress.com.

[Image removed]

Now that your domain is unlocked, click “Transfer EPP”.

[Image removed]

Under “EPP Code” is the authorization code (aka EPP code).

With that authorization code, you can complete the transfer to WordPress.com. So go back to WordPress.com…

[Image removed]

Click “Transfer”

[Image removed]

If you properly unlocked the domain earlier, you shouldn’t see the message “we couldn’t get lock status…”

Once you’ve unlocked the domain, you’ll see a field for entering the “Auth code”. That’s the Authorization Code (aka EPP code) we got from the previous domain registrar earlier (in my screenshots, it was from Bluehost).
After that, they just ask if you’d like to pay a bit extra for privacy protection. If you don’t get it, you’ll probably get a bit more spam.
And after that, you’ll just need to sit and wait for 5-7 days while the domain transfers over (your previous hosting company might be able to expedite this, just ask their support).
When WordPress.com emails you to say the domain has transferred over, you’ll just go to your Domains page, select your domain, then click on Name Servers and DNS (WordPress may send you an email requesting you confirm your contact details before you can do this.) Then flip the toggle on under “Use WordPress.com Name Servers” so that it’s blue.
Once that’s all completed, your domain will be transferred to WordPress.com, so visitors of “kitchengadgets.com” will then go to your WordPress.com site. The transfer can take up to 72 hours. (During that time, it’s possible some visitors will go to your old site and some will go to the new one. That’s always the inconvenient reality of transferring domains.)
4.2 Migrate Old Subscribers

If your old site used JetPack, it probably had some subscribers who you’d like to now follow your new site. This is called “Migrating Subscribers” from your old site to your new one.
To do that, you simply have to contact wordpress.com support (see JetPack’s instructions under “Can I use this tool to move followers from one WordPress.com site to another WordPress.com site?”) Tell them “I want to migrate my subscribers from my old jetpack site (eg ‘kitchengadgets.com’) to my new wordpress.com site” (if you’ve already transferred the domain, so your old site and your new site both had the same domain, it might be a bit confusing, but they say that won’t be a problem.)
Migrating your subscribers can actually happen while your domain is being transferred to WordPress.com. So feel free to start this step (“4.2 Migrate Old Subscribers”) while you’re in the middle of the domain transfer (see “4.1 Transferring/Mapping Your Domain to WordPress.com”, above).
What to do with your old hosting services now? You may as well cancel them, unless you have some other use for them.

All Done!

How did it go? Were there any important details I skimmed over, or things needing clarification? Tell me in the comments. Also, you can ask wordpress.com support directly, even their free help is pretty good.
Hopefully after you’ve made the switch, you’ll be happilly blogging, instead of unhappily dealing with technical issues… but if you’re not happy, there are tons of tutorials on how to switch back to self-hosted WordPress from WordPress.com [Image removed] .

Let's Decentralize Git Again

https://cmljnelson.blog/2018/08/11/lets-decentralize-git-again/ August 11, 2018

2 minute read
Doesn’t anybody else find it strange nearly all open source code is distributed on a closed-source website, GitHub, owned by Microsoft? That’s a bit like all the world’s charitable organizations being ran by a for-profit mega corporation.
As I understand it, Git’s big differentiating feature from Subversion, the big version-control system that preceded it, was that it’s distributed/decentralized/requires no central server. Everybody has their own copy of a repo, each one just as authoritative as another. This way no single organization holds all the power. This made tons of sense for GPL/free software: everybody has just as much right to use and distribute it as anybody else.
Despite that, we’re all putting our projects on GitHub. GitHub is a for-profit company. The code running their website is proprietary. They’ve changed their pricing on a whim. They’re not running on flower-power, people. They want to make a profit.
Lots of us woke up to that fact when they were bought out by Microsoft, the monopolist tech giant of yore. We liked Github. They were cool. But we don’t like Microsoft so much. Then we realized they’re the same thing. A bit like Little Red Riding hood taking Grandma’s cap off and seeing the wolf.
I don’t think Microsoft is the devil either (Google I’m not so sure- it sounds like they’re making SkyNet). I just realize they’re a private company that has a fiduciary duty to make a profit for their shareholders. So trying to make money isn’t bad. It’s literally their job.
But now we realize: GitHub is Microsoft is going to try to make money on the huge near-monopoly they have on the open-source world. Eg, if GitHub decides it will no longer offer free code repositories for open-source projects, what will we do? Most will scramble to find an alternative. But some will just pay up, knowing how much infrastructure they’ve already invested in GitHub.
When GitHub was acquired by Microsoft, GitLab has a sudden spike in activity. But, by the way, only GitLab’s community edition is free software, their Enterprise Edition, is not. So although you can run the code on your own server, they can still change the terms on you.
So what to do? I want to see us using decentralized Git again. Gogs seems to be exactly that: set it up on your own server, run it, and answer to nobody. Microsoft doesn’t control your code repository.
But Gogs obviously hasn’t taken off, most of us don’t know about it. Heck, they even host Gogs’ source code on GitHub! I think it’s problem is that setting up a server with Gogs is so, so much more work than creating a repo on GitHub. It should be way easier.
For me, I’d like it to be as easy as setting up a self-hosted WordPress site. In fact, if there were some Gogs-equivalent WordPress plugin, it could be.
Here’s what an Anti-GitHub WordPress plugin would need:

- facilitate hosting a Git repository with a few clicks, like on GitHub

- have a workflow for accepting and managing pull requests, like on GitHub

- not require Git to be installed on the server, (ie, nothing is required other than installing the plugin)

Maybe that’s a dream. But I think it would be great. Any other suggestions for how to decentralize Git again?

The Digital Dark Age & Your Blog

https://cmljnelson.blog/2018/08/12/the-digital-dark-age-your-blog/ August 12, 2018

5 minute read
We are living in the digital dark age. Wikipedia says:

the digital dark age is a lack of historical information in the digital age as a direct result of outdated file formats, software, or hardware that becomes corrupt, scarce, or inaccessible as technologies evolve and data decays.

Another way to say that: did you think computers would help preserve information? Actually, they might make it deteriorate even quicker.

Digital Data Won’t Last Forever

Eg, lets say 20 years ago you recorded your masters thesis in a Microsoft Word document and saved it to a floppy disk… well, that information is probably lost forever. It’s really hard to find a floppy disk reader, the floppy disk is probably deteriorated, and there might not be any programs that can read that old file format anymore.
Or how about this: you have a blog, like me. You hope to read from it in 20 years. Well, if you’re self-hosted, you need to keep paying the bills, otherwise the site will be taken down within a few months. Or let’s say you’re on WordPress.com, and you don’t need to worry about paying for hosting. Your blog will be around for decades, right? Maybe, assuming the company doesn’t decide your free blog is a liability and turns it off, or the company doesn’t get bought out and shut down.
These aren’t theoretical problems:

- MSN messenger, which my friends and wasted tons of time on in middle school, was shut down by Microsoft;

- all my wife’s data on FluidSurveys got erased after they were bought out;

- when the LDS Scriptures app was discontinued, I nearly lost all my journal entries…

The data we are generating today is no safer.
And would you like your children or grandchildren to be able to read your blog in 50 years? Or 100? Well, the prognosis on the data living that long isn’t good.

But Facebook Data Will Last Forever, Right?

I’ve caught myself thinking: but Facebook’s data will surely be around in 20 or 50 years, right? It’s so big, how could it disappear? Well, who knows what the future holds, but I think things are starting to sour. Here’s some things that could go wrong for them:

- people stop using it (in favor of some other social network), and then people from 50 or 100 years from now view it as cat GIFs and fake news, and so decide to just get rid of it

- government regulates it to death and decides it should be shut down and inaccessible

- your privacy settings only permit you and friends to see your info, but you’re all passed on, so the information is totally inaccessible per you privacy settings

- Facebook decides to only have paid accounts, and you either can’t pay, decide not to pay, or are dead and so can’t choose

- Facebook gets hacked and the data is corrupted

I would guess your Facebook info will probably be around 20-30 years, then it’s likely lost. We’ll see, but one thing is certain: Facebook has made no guarantee, nor can they, that your data will be kept forever.

The Typical Suggestions For Preserving Your Data

I’ve read various tips on how to preserve your data and story for as long as possible, but they all seem rooted in the 90s. They usually mention:

- Save your files, images, videos etc, to an external hard drive

- Save them to disks, or flash drive, or another hard drive, and send it to a family member or friend living far away

- Update those backups every few years, and move them onto new file formats when they become available

Those feel like suggestions from before the Internet was mainstream. Not only do they sound like a good deal of work, they also won’t work once you’re not around.
Elsewhere I also saw people suggested uploading to cloud storage like Dropbox or Google Drive. That’s probably a good solution for preserving it for 10 years, maybe 20. But Google, for example, is notorious for shutting down services once they’ve basically grown bored with them (remember Google Checkout, Google Wave, or Google Code?)
I suppose along with considering the technology, we need to consider the organization that’s preserving the data: will this organization be around for decades or centuries?

How I’d Like To Preserve My Data

In order for people to preserve their data, like stories and media, it needs to be really easy, preferably automatic.
Here’s what I’d like to see: a WordPress plugin (and extensions for other blogging platforms) that automatically sends your blog posts to:

- Family Search

- The Internet Archive

- Government Historical Databases

- Whatever other organization dedicated to preserving data you can think of

Ie, give the data to the organizations who’s purpose is to preserve that information.
Family Search is the best bet for preserving the data, in my biased opinion. They’re not only focused on family history and preserving it, but the fact it’s actually part of The Church of Jesus Christ of Latter-Day Saints is a big plus for me: they’re religiously dedicated to preserving that data. I think they’re one of your best bets for preserving your data into the next century.
The Internet Archive is trying their best to record a snapshot of every website online. They don’t have everything, but they have a lot. It has several snapshots of this blog you can peruse. But it sometimes struggles with more complex sites (for example, on their snapshot of this blog, the “Older Posts” button, which is supposed to load older posts, doesn’t work.)
Also, I slightly worry that they might run out of funding in the coming decades, or there could be legal complications to continuing it (eg, Europe’s GDPR gives websites users the “right to be forgotten“, which means if I ask for a website to take down all its info on me, they’re legally required to do that… so what happens if I ask that of the Internet Archive? Bye-bye historical record).
Various Government Historical Databases exist, although I’m not sure if they will take an interest in preserving your story, or if they will make it easy.
And I’m sure there are other good organizations dedicated to preserving data that could be added to my list (start-up companies don’t count, in my opinion, as they usually don’t last more than a decade).
I’d like this tool to work with WordPress as it’s open source, free software, meaning it will continue to exist independent of any companies. It’s also pretty ubiquitous these days. And I figure if you put something in a blog post, you probably want it to be visible today and forever. (Also, WordPress has “private” and “protected” options for posts, meaning you could have posts be private on your blog, but still be published to Family Search so that they’ll become public when you pass on.)
But maybe I’m just thinking WordPress because that’s what I’m familiar with. Maybe this could be a more generally accessible tool?

How Will You Preserve Your Data for Future Generations?

If there were a tool for automatically sending your stories, data, and media to organizations dedicated to its preservation, how would you like it to work?
And what do you think is the best way for your data to survive the digital dark age?

URL Validation in WordPress

https://cmljnelson.blog/2018/08/31/url-validation-in-wordpress/ August 31, 2018

3 minute read
If your WordPress website/theme/plugin allows users to submit URLs, and you’re not sanitizing them properly, you could have a whole host of security problems. On the flipside, if you’re removing too much, you might not be allowing valid URLs either.
This issue is pretty complex, and there’s quite a bit of confusion surrounding it, but it actually has a really simple solution in WordPress.

tl;dr; take-away

If your WordPress website/theme/plugin accepts user input of a URL, you need to either:

- sanitize it using esc_url_raw($url) before saving it

- validate it using esc_url_raw($url) === $url , and if it fails validation, reject it

Don’t use filter_var($url, FILTER_VALIDATE_URL)!

A Problematic Issue

Apparently, determining what’s a valid URL in PHP is a struggle. And it has been for a while.

“Just use filter_var” It’s So Easy…

The “PHP approved” way of doing it is to use PHP’s built-in function filter_var($url, FILTER_VALIDATE_URL). That’s the most commonly accepted answer on Stack Overflow.So, problem solved right?
Actually, using filter_var has a number of problems:

- it rejects URLs with underscores, eg http://my_site.com

- it accepts URLs that could lead to Cross-Site-Scripting Attacks, eg http://example.com/">

- it rejects URLs with multi-byte characters, eg http://스타벅스코리아.com

The problems with filter_var are explained better in this article, and discussed extensively on php.net’s documentation page.
Some have argued that filter_var is technically correct about what’s a valid or invalid URL. But really what we want is a **safe** URL, not just a technically valid one. And filter_var doesn’t do much to verify the URL is safe.
So that’s no good.

Just Make a Regex…

How hard is it to make a Regular Expression to validate URLs? Some poor soul asked that question once on Stack Overflow, and received a barrage of 19 answers. There was really no universally accepted answer (the most popular saying to use filter_var, and the accepted answer had other issues). Besides, I personally find regexes impossible to understand.

Just Find a Library to Do That…

Mika Epstein blogged about her struggles to validate a URL. She found a PHP library that mostly did it, but it still required some tweaking.
If you’re not using WordPress, you’re right to look for a pre-made library to do this, because it’s not straight forward…
I personally was quite unsatisfied that such a common task had no well-documented, good solution.

WordPress’ built-in Solution to Validating URLs

It turns out WordPress has a good option that’s super simple: esc_url_raw(). As documented here on wordpress.org, the function is meant to sanitize a URL before saving it to the database (not to prepare for outputting on the screen, that’s what esc_url() is for.)
Technically, the function is for sanitizing URLs (ie, removing bad stuff from them), not validating them (asserting whether or not they’re valid). But you can use it for validating like so:

function isValid($url)
{

return  esc_url_raw($url) === $url;

}

If the url had nothing invalid in it, then it’s valid. Pretty simple eh?
And it works well too. None of the criticisms of filter_var apply to it. We ran it through some unit tests and I have yet to see any problems with it.

Invalid URLs according to esc_url_raw():

http://example.com/"<script>alert("xss")<script>

php://filter/read=convert.base64-encode/resource=/etc/passw

foo://bar

javascript://test%0Aalert(321)

Valid URLs According to esc_url_raw():

http://foo.bar?foo=bar&other=thing

http://스타벅스코리아.com

http://localhost

A Better-Sounding, but Inferior, Alternative

There’s also a better-sounding function, wp_http_validate_url(). But from my testing, it found `http://localhost` invalid, when it should be valid. And it found URLs like  http://example.com/"<script>alert("xss")<script> to be valid.
The light documentation says this function is primarily meant for validating a URL for use in the WP HTTP API, not for storing a user-submitted URL. So although it’s name sounds better, it’s probably not what you’re looking for, unless you’re using the WP HTTP API.

Conclusion

esc_url_raw() function is used to ensure website URLs of commenters on WordPress websites are safe. Ie, it’s used to sanitize input from public users on websites running over 30% of the web, so it’s pretty battle-tested. If there was a security problem with it, or it was rejecting valid URLs, I’m pretty sure it would have already been discovered.
So is a URL valid? Just check esc_url_raw($url) === $url.
Thoughts on this?

Meeting with WordPress Professionals

https://cmljnelson.blog/2018/09/05/meeting-with-wordpress-professionals/ September 5, 2018

1 minute read
At a cafe, I met up with some local folks making their living building sites with WordPress. For me it was especially good getting a bit of a reality check, and hear what was important to them. Besides having a good time socializing (which most of us admitted we rarely do, especially on topics related to WordPress), there were a few interesting takeaways for me.
Listicle, go!

- ManageWP is so hot right now. Half of the them swore by it. They much preferred it to developing a site locally and then deploying live. In fact, one of them apparently owed everyone else a coffee because they had promised to start using it a while ago but never did. It helped immensely in keeping sites up-to-date (which is the number one cause of sites getting hacked.)

- SiteGround Cloud also sounds pretty handy. You can create a client site and manage it all yourself, and if they want manage and host it themselves (or hire someone else to do it) SiteGround will take care of moving them over to their own account painlessly.

- Divi Pagebuilder was also very popular. I know with our team it’s derided because ther are always integration problems with it, but some of our attendees loved it because their documentation is great, and they have videos for everything, which makes it especially friendly to end-users.

- Many of them don’t just do websites, but instead prefer to do all the branding services for a company. A website that’s disjointed from the rest of the marketing and branding approach of the company is likely to not be of much use.

I look forward to the next time we get together.

Introduction to the WordPress World

https://cmljnelson.blog/2018/09/25/introduction-to-the-wordpress-world/ September 25, 2018

3 minute read
This is an email I sent a friend who’s shopping around for a new career path, and I wanted to describe the “WordPress World” I work in.

Hi I really have no idea if the type of work I do would be of interest to you, but I’m happy to try to share about it and give you a taste of the “WordPress World”.
My Job for a WordPress Plugin Company

I personally work for a remote company called Event Espresso, which makes software that piggy-backs in the blogging software WordPress. I mostly just do coding in HTML, CSS, PHP, MySQL, and JavaScript. I’m more of what you’d call a software developer. There are 3 other software developers at my company. There are also 4 customer support agents. They do quite a variety of jobs: answering software users questions, help test software, help fix bugs, help with marketing and sales. And we’ve got the two owners. 3 of us are Canadian, 5 American, 1 Brit and 1 Pole.

WordPress Community

Beyond just dealing with our software, we also participate a bit in the wider WordPress community. WordPress is free software- meaning both that you can get it and use it without paying for it (although there are other expenses), and you can use it for whatever you want, know exactly what it does, and change it to suit your needs.
That means it’s basically built and maintained by volunteers (or employees of companies who voluntold them to help improve it). So I, for instance, participate in two meetings each week where we work on improving WordPress. A few of my coworkers do too (and my company pays for us to do it for one tenth of our time), but it’s not mandatory.
Most people involved in the WordPress community are freelancers, not employees of companies like me. They have a website and build websites for clients. They have a variety of skill sets and most are self-taught. Most got started with WordPress because they were helping someone else run a website or wanted a website themselves.

WordPress used to be the easiest way to run a website, but easier options have appeared since, like Squarespace and Wix. The main advantages of WordPress are: it has a huge market share, 31% of the Internet, whereas it’s nearest competitor sits around 3%; it’s freedom, because you can totally control what it does, learn how it works, and customize it; and it’s supportive community.

Getting Educated at Meetup’s and WordCamps

Besides reading free tutorials and asking questions on online forums, most WordPress “professionals” (people who’s profession centers on using WordPress, not necessarily experts yet) learn about WordPress by going Meetups and WordCamps. I recently started a local meetup which meets monthly and we take turns sharing what we know with the group. (Eg this Saturday at 1pm one member will share how they use WordPress to run a membership site and another will share about a WordPress plugin they use to speed up building websites for clients). They’re usually free.
WordCamps are bigger annual, all-day conferences. I’m planning on attending one in Vancouver October 13th. They usually cost $20.

Suggested First Steps

So if you’re interested in experiencing some of this world, here’s what I’d suggest:

1. start a blog on WordPress.com. It’s free, but it’s offered by a for-profit company called Automattic who will try to upsell you on whatever. But you’ll get the hang of how WordPress is used for blogging

2. come out to our local Meetup (see http://wpcowichan.org/) if you can. You’ll learn more about how others make a living using it, and learn about how to use it

3. read up a little on HTML and CSS (just google them). If you want to make websites for clients, or just do web design, or do customer support, or even a web developer, those two languages are the basis. There’s tons you can learn, especially because they’re constantly evolving, but I had a friend who used his weeknights to learn them and became very proficient in a couple months. He later got hired for a web development agency where I was working, honed his skills, and then moved on to become totally legit web designer. (He actually subsequently moved on from WordPress to building Shopify sites, but I think WordPress was a more friendly first step in his career.)

Does That Make Any Sense?

So that’s my professional life in a nutshell. I’m happy to try to share because it helps me learn it better. (Eg I think I learned a bit in writing this)
Let me know what you think.

6 Essential Steps To Keep WordPress From Getting Hacked

https://cmljnelson.blog/2018/09/28/6-really-easy-steps-that-will-keep-your-wordpress-website-from-getting-hacked/ September 28, 2018

4 minute read
These 6 steps will prevent 99% of hacking attempts on your WordPress website, and most of them only require a click or two, and aren’t very technical.

Of course, we all want to keep our website secure and not get hacked. It’s not fun when a hacker takes control of your website… But we also have a life and might not understand all the technical jargon. So let’s skip the fluff and get your website secure.

1. Don’t Use Easy-to-Guess Usernames and Passwords

The easiest way for a hacker to take control of your website is to guess your username and password. This may account for 8% of hacked WordPress websites. So do you have a good username and password?

Is your username “admin”? [Image removed] . That’s super easy for hackers to guess. Change your username.

You can’t just rename your “admin” user’s name because WordPress doesn’t allow you to change the user’s login. You need to create a second admin, then delete the old “admin” user. This video shows how.

And what password do you use? Does it look like “password”, “12345”, or one of the other top 1000 most-commonly-used passwords? Yes? [Image removed] . Hackers make programs that automatically try all those when hacking into your website. That’s called a “brute force” attack. Change your password.

If you have an obvious password, here’s how to change it.

2. Make Regular Website Backups

Do you have a backup of your website? (The database and files?)

Before doing the next changes, you need to make a database backup. It’s possible things might break. If so, you need a backup to restore to.

Also, if you get hacked, you’ll probably need to restore to a backup from before you got hacked. If you have no backups, you’ll need to recreate your website from scratch. Have fun. [Image removed]

If your hosting company doesn’t provide automatic backups, you can try the UpDraft Plus plugin (or search for others). It’s pretty easy to set up and the basic version is free.

3. Keep WordPress, Plugins and Themes Up-to-Date

Periodically, security problems are discovered in all software. That’s the main reason there are frequent updates to Windows, Mac OSX, and WordPress. If you don’t keep WordPress, its plugins, and themes up-to-date, you may be using an older version with publicly-known security issues. Not doing this may account for over 50% of hacks to WordPress.

But realize it’s possible that when you update, things will break. That’s why you made a backup earlier!

Simple video showing how to update plugins. Updating themes is basically the same.

WordPress should actually get security updates automatically. Every few weeks you should get an update saying “You have successfully updated to…”. If not, ask your host or developer if you’re getting automatic updates.

4. Install a Security Plugin

Here are a few ways security plugins can help keep your WordPress website secure:

- limit login attempts. This prevents a hacker from trying a “brute force” login attack mentioned earlier

- prevent suspicious requests using a firewall. Most hackers set up programs to automatically try to hack your websites. Well, security plugins can likewise detect when they’re doing that and prevent them.

- scan for suspicious changes to files. If your website gets hacked, usually the hacker’s program will change WordPress to suit their needs. Security plugins can detect when this has happened and alert you.

Wordfence and Sucuri are the two most popular security plugins. I prefer Wordfence mostly because I met the owner once at a WordCamp and he bought dinner for a bunch of us [Image removed] … And I use it and found it pretty slick.

Does your website URL start with http:// or https://?

Eg, http://mysite.com or https://mysite.com?

That little “s” stands for “secure”. Meaning that when someone visits your website, the data sent between the user’s browser and your server (eg a password when logging in, or personal information stored on the server) is transmitted securely so no one else can see it.  If you’re just using http:// it can be intercepted and read by others. (If you’d like an explanation so simple a child can understand it, I wrote and illustrated a children’s story explaining how that all works!)

In order to have your website work on https://, you need to get an “SSL certificate”. Most hosting companies can install it for you for around $40 a year, but some will give it to you one for free.

For example, here’s a short video showing how to enable HTTPS on your website (ie, get and install an SSL certificate).

WordPress isn’t the only software you need to keep up-to-date. You should also update PHP.

Currently, WordPress can work with PHP version 5.2 or higher. But older versions of PHP have security issues, and the only way to fix them is to upgrade PHP to at least version 7.0. Version 7.2 would be better, if possible.

Many hosts allow you to simply flip a switch to upgrade PHP. So it’s easy. The only trick is that some of your plugins or themes might not be compatible with newer versions of PHP…

If you upgrade and find something is broken, your host should make it equally easy to revert to the old version of PHP you were using, which will resolve the errors.

For example, here is how to update PHP on Bluehost.

That’s It

If you’ve done these 6 steps, your WordPress website is really pretty secure. This is all the things I’ve done on my sites.

If you want to spend more time securing your site, read these (ordered from least technical to more technical):

- 8 Common WordPress Security Mistakes That Could Cost You Dearly

- Yoast SEO’s Tips on Securing WordPress

- Hardening WordPress

[Image removed]

Getting Started Contributing Code to WordPress Gutenberg in Laragon

https://cmljnelson.blog/2018/10/10/getting-started-contributing-code-to-wordpress-gutenberg-in-laragon/ October 10, 2018

7 minute read
This post documents how I setup WordPress Gutenberg for local development on Windows 7, using Laragon instead of Docker, and made my first pull request to the project.

Most folks wanting to test and modify WordPress’ Gutenberg use Docker to manage their environment. That’s great because it’s especially consistent. But I’ve been happy using Laragon and wanted to attempt to avoid setting up yet another dev environment.

My Environment

I use Laragon, which runs great on Windows without needing a virtual machine (similar to XAMPP or WAMP). It comes with PHP, Apache and Nginx, Node, NPM, Git, and basically everything you need to run Gutenberg.

Setting Up a Local Test Site and Gutenberg Repo

- I forked the Gutenberg GitHub repository.

- I created a new local WordPress site using Laragon’s Quick App feature.

- Then, in the new site’s wp-content/plugins/ folder, I opened Laragon’s Terminal and ran git checkout git@github.com:mnelson4/gutenberg.git to checkout my fork of Gutenberg

- I needed to change the Node version, as the version that came with Laragon was too old. Although Laragon doesn’t come with NVM, there’s a good tutorial showing how to do that in a few minutes.

- I activated the Gutenberg plugin, which instructed me to run npm install and npm run build which I did. They took a little while but worked out ok.

After all this, I could use Gutenberg fine, and modify its source files to my liking.

Making a Pull Request

After making a fix, I wanted to create a pull request to get my changes into the master branch of Gutenberg. For that,

- I made my changes to my local checkout of Gutenberg

- ran git checkout -b my-branch to create a new branch in Git, called “my-branch”. Maybe this is unnecessary, but it seems like good practice to create a branch for changes, even in your own fork.

- ran git add {filepath} for each file I changed that I wanted to include (I didn’t use git add * because when I ran `npm run build` earlier, it made changes to package.json which I didn’t think I wanted to push)

- then git commit -m "adds my great stuff" to create a local commit

- then git push --set-upstream origin my-branchto push my changes to my GitHub fork of Gutenberg

- went to the main Gutenberg GitHub repo’s page for creating a new pull request

- on that page I needed to click “compare across forks”, then selected my fork, then my branch, then created the pull request and entered all the requested info

Then I had my first Gutenberg pull request! It was received pretty well, but it was suggested I should add an “e2e test”… which I guessed meant “end-to-end” testing. It was time to figure out what that meant!

Getting End-to-End Tests Working

Gutenberg has a ton of automated tests:

- PHPUnit tests for PHP code

- Jest tests for Javascript code

- Jest + Puppeteer tests for end-to-end testing (simulates a person manually testing from the browser)

So, I wanted to create a new Jest + Puppeteer test. Actually, first I wanted to make sure I could run those tests.

How Running Tests Without Docker Should Work

Gutenberg’s docs say you should be able to just run

WP_BASE_URL=http://localhost:8888 WP_USERNAME=admin WP_PASSWORD=password npm run test-e2e

Replacing `http://localhost:8888` with the URL of the local test site, which in my case was http://laragongut.test. But of course, that syntax is meant for Unix-based systems, not Windows. So on Windows I had to first run

SET WP_BASE_URL=http://laragongut.test

Notice that URL isn’t in quotes! If you do that, you’ll be told it’s invalid.

Likewise, I ran another command to set WP_USERNAME and WP_PASSWORD

Errors Running Tests Without Docker

But when I ran the tests, I got a long ugly error, ending in

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! gutenberg@3.9.0 pretest-e2e: concurrently "./bin/reset-e2e-tests.sh" "npm run build" npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the gutenberg@3.9.0 pretest-e2e script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

For the record, `npm run test-e2e` runs the command listed in package.json inside the scripts property with the name test-e2e. That command which begins a cascade of other commands, which eventually got to the scripts property’s pretest-e2e script, which is `concurrently “./bin/reset-e2e-tests.sh” “npm run build”`.

That last command uses concurrently to run two commands, one of which is ` ./bin/reset-e2e-tests.sh`. If you open up that bash file, you’ll see a bunch of Docker-specific logic in the (helpful) comments, like requiring a Docker instance to be running. That obviously won’t do, because I’m not using Docker.

I created an issue in GitHub documenting this error, but the fix was to change `concurrently “./bin/reset-e2e-tests.sh” “npm run build”` inside package.json to just `npm run build`, like in this commit. Then the tests proceeded ok for me (although I didn’t create a pull request for this change, because I realize the Docker setup expects that to run).

Edit: I was instructed that in the above-mentioned GitHub issue that I could instead use
npx wp-scripts test-e2e --config test/e2e/jest.config.json to run the tests. I tested that out and it works fine [Image removed] .

Timeouts During Tests

I see a ton of failures, some of which mention timeouts. So maybe my system is a bit old (yes it is, it’s getting toward 7 years old I think). It seems if you set the environment variable SET PUPPETEER_HEADLESS=false it doesn’t time out (I got the idea from this stack overflow question.) This also makes an actual Chrome browser open up, that you can see, and you can see it in action. [Image removed]

Copying Over Plugins

Some of the failures were because the end-to-end tests expected certain plugins to exist in the WordPress site which didn’t.

I read in the Docker configuration file that it copies Gutenberg’s tests/e2e/test-mu-plugins into the WordPress site’s wp-content/mu-plugins; and Gutenberg’s tests/e2e/test-plugins into the WordPress site’s wp-content/plugins/gutenberg-test-plugins. So I did that manually, then a lot more tests passed.

Running a Specific Test

It takes forever to run the entire test suite, so I wanted to usually just run a single test at a time. To do that, I cd‘d to the topmost gutenberg folder, then ran wp run test-e2e test/e2e/specs/new-post.test.js (ie, included the filepath to the test I wanted to run). And, luckily, that did indeed only do that one test!

I couldn’t find it documented anywhere, but any extra arguments you pass into wp run test-e2e get forwarded onto however jest is finally called. So, with jest you can request to only test one file by doing jest path-to-file.

Writing My Own End-to-End Test with Jest and Puppeteer

To get started writing my own Jest + Puppeteer test, I skimmed over each’s getting started documentation, then tried to copy everything I could from the tests already written, like test/e2e/specs/new-post.test.js.

So I created a new test file, in test/e2e/specs/new-post-default-content.test.js, and also a new plugin in test/e2e/test-plugins/default-post-content.php.

The plugin changes the editor’s default title, content, and excerpt. The test activates that plugin, then verifies it successfully modified the editor’s content.

Gotcha: at one point, I used SET WP_BASE_URL=... to attempt to change the system variable. It didn’t change it at all. You need to just close down all the terminals, and open new ones, and it will get reset.

Committing the End-to-End Test

My addition of the end-to-end test was more substantial, and affected actual javascript code (well, Javascript test code anyway). So when I tried to commit it like before, it noticed some code style errors and refused the commit.

Ie, I saw

husky > npm run -s precommit (node v10.5.0)
25lRunning tasks for packages/*/package.json [started]
Running tasks for *.scss [started]
Running tasks for *.js [started]
Running tasks for {docs/{root-manifest.json,tool/*.js},packages/{*/README.md,*/s
ctors}.js,components/src/*/**/README.md}} [started]
Running tasks for packages/*/package.json [skipped]
→ No staged files match packages/*/package.json
Running tasks for *.scss [skipped]
→ No staged files match *.scss
Running tasks for {docs/{root-manifest.json,tool/*.js},packages/{*/README.md,*/s
ctors}.js,components/src/*/**/README.md}} [skipped]
→ No staged files match {docs/{root-manifest.json,tool/*.js},packages/{*/README.
s,selectors}.js,components/src/*/**/README.md}}
eslint [started]
eslint [failed]
→
Running tasks for *.js [failed]
→
25h× "eslint" found some errors. Please fix them and try committing again.
E:\Software\laragon\www\laragongut\wp-content\plugins\gutenberg\test\e2e\specs
ew-post-default-content.test.js
4:8   error  A space is required after '{'                 object-curly-spacing
4:16  error  A space is required before '}'                object-curly-spacing
5:8   error  A space is required after '{'                 object-curly-spacing
5:41  error  A space is required before '}'                object-curly-spacing
7:9   error  There must be a space inside this paren       space-in-parens
8:11  error  There must be a space inside this paren       space-in-parens
9:23  error  There must be a space inside this paren       space-in-parens
9:68  error  There must be a space inside this paren       space-in-parens
10:3   error  There must be a space inside this paren       space-in-parens
12:12  error  There must be a space inside this paren       space-in-parens
14:3   error  There must be a space inside this paren       space-in-parens
16:10  error  There must be a space inside this paren       space-in-parens
17:25  error  There must be a space inside this paren       space-in-parens
17:70  error  There must be a space inside this paren       space-in-parens
18:3   error  There must be a space inside this paren       space-in-parens
20:4   error  There must be a space inside this paren       space-in-parens
20:51  error  Block must not be padded by blank lines       padded-blocks
24:4   error  There must be a space inside this paren       space-in-parens
24:12  error  There must be a space inside this paren       space-in-parens
27:9   error  'content' is assigned a value but never used  no-unused-vars
27:31  error  There must be a space inside this paren       space-in-parens
27:49  error  There must be a space inside this paren       space-in-parens
28:9   error  'excerpt' is assigned a value but never used  no-unused-vars
28:31  error  There must be a space inside this paren       space-in-parens
28:63  error  There must be a space inside this paren       space-in-parens
29:9   error  There must be a space inside this paren       space-in-parens
29:15  error  There must be a space inside this paren       space-in-parens
29:21  error  There must be a space inside this paren       space-in-parens
29:40  error  There must be a space inside this paren       space-in-parens
30:3   error  There must be a space inside this paren       space-in-parens
31:2   error  There must be a space inside this paren       space-in-parens
31 problems (31 errors, 0 warnings)
29 errors, 0 warnings potentially fixable with the `--fix` option.
25h
husky > pre-commit hook failed (add --no-verify to bypass)

Which is kinda cool- it verifies the code meets the project’s code style guidelines, or else rejects it (although it does give you the option to workaround it).

Rather than go through that list of code style errors and fix them manually, I discovered a script I could use. I ran npm run lint-js:fix (mentioned in the project’s package.json file) and it took care of automatically fixing nearly all the code style issues [Image removed] .

Then I tried the commit again, and it worked.

Javascript That was All New To Me

For someone who’s been doing mostly PHP for the last several years, there was a lot of alien-looking Javascript. Here’s some highlights:

- const means a constant “variable”, so it can’t be reassigned in the current scope

- const [myConstant] = some_function() will expect some_function() to return an array, and it stuffs its first result into the new variable myConstant

- `const foobar = await getEditedPostContent()` is a weird one. The function `getEditedPostContent()` doesn’t just return a regular value, it returns a Promise… which is a bit asynchronous weirdness. But adding `await` before it turns it back into a synchronous, normal function. Specifically, normally promises allow the function to complete before it has a return value, but await tells it to instead forget all that asynchronous nonsense, and not proceed until the function has a regular return value, and then stuff it into the variable foobar

- `page.$eval(selector)` is a Puppeteer function that searches the current page using the CSS selector;  `page.$x(…)` is also a Puppeteer function that does the same thing but uses xpath

Ok I’m Done Now

Good luck with getting started contributing to Gutenberg! Let me know if you have any questions in the comments, or what struggles you’ve had. Also, the folks in WordPress Slack’s “core-editor” channel might be helpful.

PHP's array_shift Performance

https://cmljnelson.blog/2018/10/16/phps-array_shift-performance/ October 16, 2018

1 minute read
PHP’s array_shift is a relatively slow way to fetch the first item from an array; it’s much better to use reset.

array_shift() modifies the original array and can be pretty slow because it needs to completely reindex the array (remove first element then shuffle everything else forward by one “slot”), so unless you specifically need to continue to work with the array after removing the first element, it is far far more performant to use reset() which simply rewinds the array pointer to the beginning then returns the first element.

Even reversing the array, using array_reverse() followed by array_pop() to remove and return the last element (the element previously known as the first element) is faster than using array_shift(). Results are likely different in newer versions of PHP, but in this article they removed 1000 elements from a 100,000 element array, with the following results:

array_pop takes 0.00089 seconds
array_shift takes 15.15544 seconds
array_reverse + array_pop takes 0.03934 seconds

I realize we will never be dealing with arrays that large and the result may be negligible for this code, but it doesn’t hurt to know what you are working with.

This content is entirely from our lead developer, Brent Christensen, internal code review… I just thought it was such a good point that the world needed to know!

WordCamp Vancouver 2018 Memory Dump

https://cmljnelson.blog/2018/10/16/wordcamp-vancouver-2018-memory-dump/ October 16, 2018

9 minute read
Absolutely everything I can remember from my WordCamp experience this year. Feel free to just skip to the sections that interest you…

(And thanks Esther for the photo of Scott, myself, and Jason on the ferry!)

Preparation

I sent a message out to my WordPress meetup and “WordPress professionals” group asking if anyone wanted to carpool.

I was lucky enough to have a full carload with whom to share the ferry costs! So instead of paying about $300 for transportation (last time I flew) it was more like $75. So, there you have it: a direct benefit of participating in a meetup!

Journey There

Like most mornings when I needed to awake early, I couldn’t sleep the night before. So from about 3 am to 4:30 am I tossed and turned, anxious that I might have set my alarm clock incorrectly or something.

By 4:30 am I just resigned myself to not sleeping, and had pre-breakfast and headed out. I thought I might have heard my 2 year old stirring but luckily she didn’t get up.

I picked up my fellow Shawnigan Lake WordPresser, Jason, at 5:07, 3 minutes earlier than we planned, then Esther and Scott at 5:37am, 3 minutes early, in Victoria. None of them slept well either, and were all running early (which is much, much nicer than running late!)

Main benefit of this early morning: we were some of the first to board the boat, so we got our choice of seats and watched a fabulous sunrise while sailing through the gulf islands. [Image removed]

We then arrived at WordCamp a little late (after the opening remarks) but just a few minutes into the first round of presentations.

Presentations

Building Progressive Themes with WP Rig, by  Morten Rand-Hendriksen

- main purpose is to allow you to use modern html, js, css, today while maintaining backward compatibility

- does all build stuff.

- allows you to only include css used on the current page

- Morten mentioned that there’s a growing standard to load css inline (not just in head). This way the css is only loaded when the browser gets to that part of the page.

- css variables aren’t supported by most browsers, but wp rig acts as a shim

- when you start using wprig to build a theme, it’s now your code. Your code and the WP Rig code are tightly coupled and it’s expected that you won’t update WP Rig. (I can see how this is nice because “you don’t need to update”… although I can see if there are new WP Rig features in the future, or even security issues, it would be nice to have WP Rig separate and easily updatable.)

- checkout wprig.io

Just enough React: Getting ready for Gutenberg, by Shannon Smith

I was hoping Shannon’s presentation would be more of an overview of the React Javascript framework, but ended up being more of an introduction to Gutenberg (WordPress’ new post editor, which is primarily being pushed by the company Automattic, not so much the entire WordPress community) which dabbled in how to develop blocks. Given she’s an Automattic employee, I’m also suspicious that she was assigned to generate excitement over Gutenberg. Still, there were some good takeaways from her presentation for me:

- when registering custom post types, you can declare its Gutenberg Template

- you can use command line (WP CLI) to scaffold Gutenberg blocks

- Gary Pendergast created a plugin to convert shortcode to blocks (although TBH I can’t find it; all I could find was Daniel Bachhuber’s tutorial on how to do it)

- most theme and plugin devs don’t need to learn react to build blocks etc. Only need react for contributing

How to Optimally Secure Your WordPress Environment, by Chloe Chamberland & Colette Chamberland

- there no single way to prevent all hacks. Need layers and backup plans

- big factor in security is choosing a good host. They should maintain 30 days of access and error logs, use SFTP instead of just FTP, use mod security, clamAV, keep backups for at least 30 days (or find find plugins for those; although configuring SFTP etc is something you can’t do with a plugin)

- use haveibeenpwned.com to see if your email has been compromised in a data breach on some website (I just used it, and my faithful old email from the early 2000s has apparently been compromised a half dozen times [Image removed] )

- PCI (security standards for website processing credit card payments) requires you use TLS 1.1 after June 2018

- there are two main types of firewalls, both with PROs and CONs: cloud-based firewalls (which run on a remote server, I think is what Sucuri offers) and application firewalls (which run on your website, which is what Wordfence offers). Which is better? Both.

- cloud based firewalls use DNS, so you set your site to use their DNS and they forward requests onto you, after running them through their firewall. But a hacker can discover your IP address and then send requests directly to you, which bypasses their firewall.

- if you get hacked, first thing you should do is take the site offline, review logs to find out when it was hacked, notify customers, and restore to a backup. (And if you don’t have a backup, hire someone to clean your site or start from scratch!)

- California has recently passed a law requiring no simple passwords

Stop Guessing: Diagnosing & Fixing WordPress Performance, by Matt Kopala

- page cache is ultimate in speed, but has downsides (like needing to be refreshed periodically, which is obviously slow, and it might be hard to cache the entire site, and you can’t cache the admin dashboard)

- object cache helps across all pages

- but it’s best to have a fast site without caching

- webpagetest.org is good way to assess how fast site is (I just tried it on my wpcowichan.org site… [Image removed] the results were far poorer than I thought they’d be!)

- how to check if host is cause of slowness? Try a different host and copy the site there, then compare results

- new relic now has WordPress integration, shows performance of plugins

- beaver builder usually really slow, so is JetPack

- it’s not the number of plugins that’s important, but what they’re doing and how they’re configured

- jpgs generally much better than pngs

- if you don’t have server access to install new relic, try a host that allows that (hint: sitedistrict) run new relic then, and assess how to speed it up, and you can always go back

Webpack for WordPress, by Carrie Forde

- minimizes, and compiles JS and CSS

- but can be made with source map so errors and js console show what original file that came from

- Babel module can take care of converting modern js to legacy js

- gulp, (grunt?) and webpack kinda serve the same purpose

Running 25 plugins (and other things my professors told me not to do), by Ryan Chmura

- make mistakes but fix them

- having a pixel perfect layout actually doesn’t do a ton for increasing traffic

- while a good personality usually doesn’t trump efficiency, all things being equal, most people would prefer to work with someone pleasant and fun

- communicate even if things are your fault

- what contributed to his site’s growth? Social media marketing and contests

It’s funny that even though Ryan was obviously pretty new to WordPress (undoubtedly many of us felt more experienced than him) this was the talk my carpool groupy talked about the most. We liked his effort and emphasis on the important things (like focusing on getting traffic and features that will actually help the business, not making things pixel perfect or poetic code). And for my part, I like seeing more involvement from younger folks.

How to Stay Calm and Troubleshoot Your WordPress Code, by Kirsten Starcher

- when clients are upset, just hear them out and acknowledge them

Hallway Chats

I’ve started to find meeting people at meetups really easy, to be honest. I just walk up to other folks who’re snacking, or waiting for the next session, and ask “So, what do you do with WordPress?” And they usually mention something they have experience with that I’d like to know more about, so I’ll ask them about it. Somewhere along the way, I’ll tell them what I do and share something about myself too (just to clarify it’s not an interrogation, but I’m interested to learn from them).

Kalen Johnson

That’s how I met Kalen Johnson. He described himself as not being so into WordPress, mostly a general PHP developer. He was also a formidable opponent at Mario Kart 64 at the Blue Host sponsor booth.

[Image removed]

Mario Kart 64 at the Blue Host sponsor booth.

Kalen and I played with one of the Blue Host reps. He said if we beat him, he’d give us another ticket for the raffle to win the TV… and somehow, I got lucky and the game (despite initially not remembering which buttons to use!)

I offered the ticket to Kalen but he gracious declined… boy would he regret that…

Rob Golbeck

Afterwards I met Rob Golbeck. He was plenty friendly. He’s a WordPress site builder living in Tsawwassen. Here’s some of our conversation’s highlights:

- being a freelancer, most referrals he receives are from a local business/entrepreneurship group he attends, and from previous work connections (not SEO or social media etc)

- he uses the Pro Theme with their page builder

I couldn’t use my raffle tickets because I was going to leave early to catch the ferry, so I gave them over to Rob. I said, “If you win, give me a tweet on Twitter or something!”

That evening, he tweeted this:

[Image removed]

Rob Golbeck’s tweet announcing his winning- apparently with the ticket I gave him! [Image removed]

Wordfence Folks

This was one of the highlights of the WordCamp for me.

First off, they had a fun sponsor booth. Mark Maunder was there teaching people how to pick locks. I don’t totally follow why, but it was really fun. And if you managed to pick the lock, he gave you your own lock picking kit.

[Image removed]

Lock picking kit from Wordfence.

While I don’t plan to take up breaking-and-entering, it was fun and informative. The point being that if you understand how intruders work, you can better defend against them. And of course that’s exactly what Wordfence is all about, just online.

I like the idea that actually understanding how to attack helps you better defend. I asked him how exactly do you intercept HTTP packets. Apparently on public Wifi it’s pretty trivial: just

1. connect to the network (like everyone else),

2. setup a packet sniffer on your local computer

3. set it to promiscuous mode (which causes the computer to listen to packets not intended for it; normally computers ignore all network messages not intended for it)

4. watch the HTTP messages on the network.

At DefCon, a cyber security conference, they illustrated this by setting up the “Wall of Sheep“. It’s where they do exactly what I described above, and have a program analyze the HTTP messages for usernames and passwords, then put them on a projector for everyone to see to shame folks using insecure websites.

[Image removed]

DefCon’s “Wall of Sheep”. Mark pointed out to Collette they should do these at WordCamps, too. I agree that it would certainly catch everyone’s attention!!

We agreed it would super informative, albeit ethically uncomfortable, to have a WordCamp presentation showing how to hack WordPress websites, with the purpose of learning how to better protect it.

Later, Mark mentioned that one of their developers previous worked in military defense, basically defending nuclear installations. So that’s the calibre of hires they do- people get promoted from nuclear defense to WordPress defense…

That of course brought up Red Team Operations, where one of their own staff (usually Colette Chamberland) will secretly try to hack their own system. Apparently their ex-government employee had such an operation working in nuclear defense once, and they didn’t realize it was just an internal exercise, and they nearly alerted the president of the United States.

We also talked about why folks become malicious hackers, in the first place. Mark mentioned how back in his youth, he was a bit of a hobbyist hacker. It was basically a game, a bit like egging someone’s house. He quit when he heard the news of someone being put behind bars for similar hacking. Apparently the USA is one of the harshest on countries on cyber criminals.

Anyways, really interesting stuff. (FYI here’s a great WordPress.tv session with Mark and other Wordfence folks on security that’ll give you a taste of what type of stuff we were chatting about.)

Soren Henrich

I met Soren and he was nice guy, building sites like most attendees. He gave me a good opportunity to explain the merits of a self-hosted registration system, as opposed to something like eventbrite.com.

What was also fun was we bumped into him on the ferry on the way home. He was taking the bus, and we had an extra spot in the car, so he got a lift with us.

[Image removed]

Jason, Esther, Soren, Scott, and Me, in the car on the drive home

My Highlights

- Young folks presenting. I think we could do a lot more to encourage younger people to use WordPress.

- I really enjoyed my hallway chats; those may have been my highlights.

- Road tripping it with friends. In some ways I wish we’d have a closer WordCamp, without needing to get up so ridiculously early, but it was a lot more fun this way.

- I enjoyed the N64 games and lock-picking sponsor booths. What’s more, I think they may have been better at getting people to come over and interact instead of just pushing their product.

- While it’s cool having “big name” presenters from afar, it’s kinda nice having local presenters too. When someone spends big money to come present, I suspect there’s more of a burden to get a return on investment (eg subtly promote their product). I think there was less of that from local presenters.

- have lunch above ground. At WordCamp Seattle last year, each person was given a voucher for a nearby restaurant. The walk was refreshing and a good opportunity to bump into other WordCampers

- Another track for more hands-on opportunities, like getting dirty with code, or a a help desk

- Bring aspirin or something. I think the early morning and being underground all day gave me quite a headache.

Any other memories other attendees wants to share?

Welcome, Old Blogspot Posts

https://cmljnelson.blog/2018/11/22/welcome-old-blogspot-posts/ November 22, 2018

5 minute read
Today, I finally brought my old Blogspot blog’s posts, cmljnelson.blogspot.com, over to my WordPress.com blog, cmljnelson.blog. I’m pretty happy with how it went, so I thought I’d share why and how I did it. Also, my blog’s timeline now looks weird, with about a 5 year gap of zero blog posts, so I thought I should explain that.

Why I was on Blogspot to Begin With

I was taking a Computer Science class at BYU which required us to have a blog. There was no required technology, but we just needed to have a public blog and use it. That was actually a very good idea, in my opinion. It forced us to “get with it”- not just understanding how to code, but understanding the culture and trends. One of which is blogging. I’ve found blogging helpful, like keeping a good journal. Except it’s searchable. And I get to share what I learned from others. And others can correct me when my ideas are out-of-whack.

Anyways, I was aware of WordPress at the time, but only the self-hosted variety. I was busy with classes and socializing, and wasn’t interested in installing yet another thing. In retrospect that was a shame, because actually running a website on a webserver myself would have been great for my education (I would have had a lot more practice understanding DNS, SSL, server-side languages, security, performance, etc.) But I took the quickest option that got me the grade: blogspot.

Why Version 2 of My Blog Is on WordPress.com

After the course was done, I blogged once or twice, but that was about it. I was engaged and twitterpated and forgot all about it. Somehow I wound up working with WordPress for my living, and found myself wanting to share my learning and opinions with the world. Also, I had a master plan to basically keep a public journal (blog), and then try my best to make it available to my children and descendants a few decades from now. (That plan is actually coming along ok; more to follow…)

But the main gist of it was: I wanted experience actually using WordPress, not just developing it. Also I wanted the option to own the data myself. Someday, when I’m not so cheap, I hope to get a self-hosted WordPress blog. Then I’ll run my blog with whatever plugins and code I want. WordPress.com is the middleground, because I figure it will be easy enough to migrate to self-hosted later.

Also, I started a new blog because I kinda wanted a fresh start at it, and somewhat forgot the old blog existed.

Why Did I Jump Ship?

Why did I decide to totally abandon my old Blogspot blog, and move its posts over to WordPress.com? Because I’m afraid Blogspot is becoming abandonware, and my feelings towards Google (which runs blogspot) have soured.

My wife, Amanda, also has a Blogspot blog, primarily just for recording recipes. She used their mobile app. But she noticed yesterday that it doesn’t work anymore. That suggests the product isn’t too healthy.

I really haven’t heard about anything new or cool blogspot is doing. It seems like it was great 8 years ago, but it’s really been stagnant since. WordPress is that old too, of course, but it’s development is accelerating, if anything.

So I was afraid Blogspot would be shut down soon, like Google Wave, Google Checkout, Google Code, etc. So I wanted to abandon ship before it sank.

Oh, and another point: Google is currently buying up a bunch of WordPress core committers and paying them to work on WordPress. So it seems they’re shifting to supporting WordPress also. I think Blogspot’s days are numbered.

How Did I Make the Switch?

The article “How to Switch from Blogger to WordPress without Losing Google Rankings” from wpbeginner.com was helpful. It’s explains how to migrate to a self-hosted WordPress site, so it didn’t 100% apply. But it got me started. Here’s what I did:

“Backed up” my Blogspot blog. That got me a machine-readable file with all my Blogspot’s content. I didn’t actually have any images, so that may have simplified things.

[Image removed]

How to Export Blogspot blog

Afterwards, I logged into WordPress.com, clicked “Import”, then found the Blogger.com row (to be honest, I’m still confused what the difference is between Blogger and Blogspot, basically they’re the same) and clicked “Start Import”. I then selected the file I downloaded from Blogspot earlier. It took a few minutes, but got all my posts over. And they looked just fine.

[Image removed]

How I Imported my Blogspot posts into WordPress.com. “Import” then in the “Blogger.com” row, “Start Import.”

The last thing I realized I wanted, was to forward my Blogspot blog over to my WordPress.com blog.

Back in Blogspot, I went to “Themes”, then clicked “Edit HTML”.

[Image removed]

Then, right before </head>, I added

var l = window.location.href;
window.location = l.replace('cmljnelson.blogspot.com','cmljnelson.blog');

So it looked like this:

[Image removed]

That redirected users from “cmljnelson.blogspot.com” to “cmljnelson.blog” just fine. What’s more, the URLs I imported from Blogspot are identical, except they’re on “wordpress.com” instead of “blogspot.com”.

Note: if you’re wanting to redirect visitors from your blogspot blog, you’ll probably need to modify my code snippet above. Specifically, replace cmljnelson.blogspot.com with your old blog’s domain name, and replace cmljnelson.blog with your new blog’s domain name.

After that, I just needed to disable Blogspot’s “mobile theme”, so mobile users got redirected to WordPress.com too.

Errmm, So What’s Up With My Blog’s Timeline?

All my posts from 2010-2012 were imported from Blogspot. Everything else was written on WordPress.com. I guess that was pretty simple to explain.

So, What if You’re on Blogspot?

So if you’re also on Blogspot, don’t feel obliged to run away from it urgently or anything. Even if they do decide to shut it down, they’ll give you plenty of warning, and give you a chance to export your posts from it.

Just for me, I decided the time had come to move on. Simply put, Blogspot is slowly dying. If you don’t want your blog to be a victim of the Digital Dark Age just yet, I think it’s time to move it too.

Improving Online Team Decision-Making and Discussion

https://cmljnelson.blog/2018/12/18/improving-online-team-decision-making-and-discussion/ December 18, 2018

The Really Easy Way to Make a WordPress Plugin Translation-Ready

https://cmljnelson.blog/2019/01/01/the-really-lazy-way-to-translate-a-wordpress-plugin/ January 1, 2019

3 minute read
Making a WordPress plugin available in a user’s preferred language used to be more complicated. Now it’s really easy. I want to share the up-to-date way (as of 2019) to get your plugin ready for translating into everyone’s languages.

I’ll skip the complexities of translations and get right to it.

1. Set Your Plugin’s Minimum Version of WordPress to 4.6

In your plugin’s readme.txt file, add
Requires at least: 4.6 . Here’s an example of a plugin’s readme.txt file:

=== Print My Blog ===
Contributors: mnelson4
Tags: print, pdf, backup
Requires at least: 4.6
Stable tag: trunk
Tested up to: 5.0
Requires PHP: 5.4
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

(As a reminder, the readme.txt file is different from the plugin header comment.)

Requiring WordPress 4.6 allows your plugin can take advantage of all the latest simplifications for translations. If you need your plugin to work with older versions of WordPress, then sorry: this tutorial won’t help you. In that case, you’d be best reading the developer documentation.

If your Plugin is in the WordPress plugin repository, WordPress will take care of a lot of the complexity for you. If you don’t want to put it in there, again, sorry these simplified steps won’t work for you.

So, follow the steps for getting your Plugin into the repository. Don’t worry about translations yet, just get it into the plugin repository in English.

3. Use the Translation Functions in your Plugin

Now, in your plugin’s code, use WordPress’ translation functions. For example, instead of doing $my_string = "foo bar"; in your PHP, and <b>foo bar</b> in your HTML, do $my_string = __("foo bar", "your-plugin-textdomain"); in your PHP and <b><?php _e("foo bar", "your-plugin-textdomain");?></b> in your HTML.

Read more about WordPress translation functions if you’re not familiar with them.

4. Use the Right Text Domain for Your Plugin

The important part is using the correct translation domain. Go to your plugin’s page on the WordPress plugin repository. The URL will be like https://wordpress.org/plugins/your-plugin-slug/. That last part of the URL, “your-plugin-slug”, is your plugin’s slug. That’s what you use for the translation functions’ text domain.

For example, I have a plugin located at https://wordpress.org/plugins/print-my-blog/. So it’s slug is “print-my-blog”. So when I use translation functions, they look like $my_string = __("foo bar", "print-my-blog");.

The Results

If you do the above steps, WordPress will take care of:

- Parsing through your Plugin for all the translatable strings (no need to install and run Poedit or anything)

- Make it easy for anyone to contribute translations of your plugin on translate.wordpress.org (no need to have your own site dedicated to translating your plugin, or having a custom process for translators to submit their translations to you)

- when someone uses your plugin, WordPress will take care of checking if it’s translates into their language, and if so, showing it in their language (no need for them, or you, to load the translation files onto their website)

For more info, please read How to Internationalize Your Plugin.

Let me know if this could be clearer or I got anything wrong.

Final Note: Approving Translations

After all the above, your plugin is ready to be translated on translate.wordpress.org. BUT translations made there need to be approved by a Project Translation Editor (PTE). If you would like to approve translations for a language you speak for your plugin you need to request that on make.wordpress.org/polyglots, and someone from the language’s team will get in touch. (Eg here’s where I requested to become a PTE for the French and Spanish).

Anyways, that’s it. C’est tout. Terminado. Finito.

Update: I originally titled this “The really lazy way to translate a WordPress plugin”, but despite preferring that name, I realize very few people will be searching for the term “lazy.” “Easy” is much more common and truer to the point of this article.

Preserve your Story with "Print My Blog" WordPress Plugin

https://cmljnelson.blog/2019/01/15/preserve-your-story-with-print-my-blog-wordpress-plugin/ January 15, 2019

3 minute read

[Image removed]

A few months ago I wrote about how most current digital content, including blogs, probably won’t be readable in 100 years. Quite a few commenters said they really just want to make a paper copy of their entire blog, but there’s no easy way to do that.

So, a few weeks ago I created a WordPress plugin that makes it easy to print your entire blog. It’s called Print My Blog, and is available for free download from WordPress.org. After installing it, it’s just 2 clicks to create a paper or PDF copy of your entire blog. It also avoids printing ink-guzzlers, like your site’s header image, menus, or sidebar widgets. It just prints your blog’s content, the stuff you’d want to read.

Here is a 2 minute video showing “Print My Blog” WordPress plugin to create a PDF of my entire blog.

What’s the Big Idea?

Preserve what you’ve published. It’s great that you have a blog or website, it allows your voice to be heard throughout the world… so long as your blog is still online. And once you’re gone, so is your blog. So how will future generations know what you said, or even that your blog ever existed?

The question of how you preserve your blog’s content after your blog is gone is a tough one. But since antiquity they’ve had a pretty good solution: keep a good old, physical copy. Paper.

A paper copy can survive in situations your digital blog won’t. You can still read it when: you stop paying hosting bills, or you’re disconnected from the Internet, or your website’s software becomes several decades old, or your hard drive gets corrupted. It may get a little worn, but it’s available and readable.

And although paper isn’t totally future-proof (it can get wet, or burned, or lost), keeping a paper copy of your blog will help preserve it.

[Image removed]

Why Else Would I Want to Print My Blog?

There are a few other situations printing your entire blog is useful:

- some people just prefer to read on paper

- going on a trip? Print an entire blog to paper, or PDF and save to your phone, so you can read it while you’re disconnected

- If you’re shutting down a website or blog, make a PDF copy of it and share it on DropBox or Google Drive.

- Lastly, create a slideshow presentation using your website, and create a PDF you can present and upload to SlideShare

Features

Current features:

- Works with hundreds of posts (largest blog so far had over 500 posts with images and produced a PDF over 400MB)

- Works with WordPress posts (ordered by date) or pages (ordered hierarchically)

- uses your theme’s stylesheet, but doesn’t show your theme’s header, sidebar widgets, or footer

- resize text and images (or remove images altogether)

- put text into columns to give it a newspaper-like look

- show posts’s categories and featured images

In-the-works or planned:

- content selection: just print posts in a date range or category

- web service, so WordPress.com users can print their blog for free without even needing to install the plugin (this is partially done, contact me if you’d like to try it out early)

- replace internal HTML hyperlinks with page references in printouts

- replace external HTML hyperlinks with footnotes

- add a table of contents to the top (with links to actual page numbers of posts)

- whatever other good ideas get suggested

How You Can Help

The point is this: make it as easy as possible to make a paper or PDF copy of your blog, so future generations can benefit from it.

I’m currently doing this as a public service, and would appreciate your help. Here’s what you can do:

- Try it. Let me know how you’re using it, what difficulties you had, and what you’d like to see in the future (on GitHub or the WordPress support forum).

- Share It. If it saved you time and you think it’s useful, tell your friends and leave a plugin review

- Translate It. You can help make it usable by non-English speakers.

Let’s preserve your blog for future generations!

Are WordPress’ "Small d" Developers Getting Left Behind by “Modern Best Practices”?

https://cmljnelson.blog/2019/02/05/are-wordpress-small-d-developers-getting-left-behind-by-modern-best-practices/ February 5, 2019

5 minute read

[Image removed]

A pig missing the plane in Richard Scarry’s What Do People Do All Day?

After years of being derided as not being with the times, WordPress’ code and community is experiencing a cultural shift in adopting “modern best practices.” Examples of this are the emphasis on Javascript (and especially the React framework), introducing a build process, and increasing the required minimum version of PHP.

While this helps professional WordPress developers feel less shame about their CMS of choice, I hope we don’t forget about the “small d” developers (a term inspired by “small b blogging“). By that, I mean people who want to build with and contribute to WordPress, but don’t have years of experience with it or the opportunity to do so full time. I worry that, for them, all these new developments make developing with or contributing to WordPress unapproachable.

“Small d” developers can be easily overlooked. They probably aren’t able to attend the weekly WordPress core dev chats, nor do they have a booth at WordCamps. But serving them has been a core component of WordPress’ mission and success. To me, WordPress’ mission to “democratize publishing” doesn’t just mean to enable as many people as possible to publish what content they want, but also to enable as many people as possible to understand and contribute to the software used.

Abandoning What Got Us Here

We have been told “what got us here, won’t get us there“, axiomatically implying fundamental changes are needed to WordPress (both the software and the community) in order to progress further. But when “what got us here” served us well enough to supercharge niche software to becoming a third of the Internet, I think we need to be cautious about abandoning it.

“What got us here” has been a preoccupation with understanding real users’ problems, instead of bored developers’ imagined ones. On the other hand, “what will get us there”, complicated Node.js dependency trees, fragile new build processes, and breaks in backward compatibility, sounds a lot like the ethos of other CMSs. Ones that are losing ground, like Drupal and Joomla, despite how much “real” developers love them. “What will get is there” doesn’t seem to have a great track record, so why are we adopting it?

We Don’t Use What’s Best, We Use What’s Easy

[Image removed]

Satellite dish, like those used by our Church for receiving video broadcasts

At Church there is an expensive, complicated system for receiving video broadcasts from church headquarters, which now sits totally unused. It’s been replaced by online video streaming, which is far lower quality and less reliable, but is much easier to use. It doesn’t take any special equipment or training, and so that’s what we use.

WordPress’ success story has a similar theme: it’s never been the most well-designed CMS, it’s just been easy to install, write with, develop with, and contribute to. “Modern best practices” are removing the simplicity that made WordPress popular to begin with.

Don’t be Bullied into “Best Practices”

As a developer, you feel bad when someone mocks your work because it doesn’t conform to “modern best practices.” It’s easy to get bullied into wasting considerable time and resources to chase the ever-changing criteria of “modern”.

[M]any best practices are purely folklore. No one knows where they came from, why they started, and why they continue to be followed.

It Doesn’t Have To be Crazy at Work – by Fried, Jason; Hansson and David Heinemeier Hansson

If the only reason you’re being told to change is order to “follow best practices”, don’t fall for it! You should change when there is a measurable benefit, not just theoretical promises.

For example, should a plugin change all its shortcodes into Gutenberg blocks? It’s basically a best practice now. And yes, blocks are more user friendly than shortcodes. So sure, it’s a good thing to do. But if those shortcodes are nearly never used by regular users, and making this change will delay features or big fixes users are clamoring for, maybe it should wait.

If a best practice addresses an important problem you’re actually having, then yes, it makes sense to apply. But if it has hollow promises of making things better someday, it’s delaying features or bug fixes that actually matter to your community, and it’s making your software harder to work with for real users, it sounds like one of the worse things you could do.

Are “Small d” Developers Less Intelligent?

The new technologies required to learn and use WordPress can make it harder for “small d” developers to work with. Is that because they’re less intelligent? In which case, losing their participation and contribution might almost be good, right?

My definition of “little d” developers is that they have less experience doing software development. But that also implies they have more experience elsewhere… like working with clients, actually using the software, or dealing with the myriad of other tasks involved in a successful business or organization. So, they have a breadth of knowledge that is actually vital to developing useful software.

For example, who is most likely to make the most useful blogging software? Probably not a computer scientist, but a blogger. One who knows just enough about creating software, but who has a lot of experience outside of the bits and bytes.

If the software becomes too difficult for that blogger to contribute, you’ve lost your most valuable contributor.

That’s one reason WordPress’ simplicity has been so important: it doesn’t just enable “less intelligent” people to participate, but also very intelligent people, not just full time developers, to contribute their breadth of expertise.

The Best Practice of Remembering “Small d” Developers

“Small d” developers aren’t “Small h” humans with nothing to contribute. Their expertise is just in variety of areas as opposed to one.

So what can be done to not leave “small d” developers behind, but still appease “Big D” developers craving “modern best practices?” Here are my thoughts:

- Don’t force WordPress developers to learn current JavaScript development overnight (Gutenberg block’s server-side render is a good effort towards this).

- Help WordPress developers learn modern JavaScript. Yes, they can search the Internet for React, Node, NPM, webpack, lodash, babel, jest, and all the rest of the new JavaScript dependencies by themselves. But deciphering how all those moving pieces work together, and how WordPress uses them, is a mess they could use help with.

- Don’t require everyone who wants to run WordPress’ development version to run the new build process. There were recent efforts that required you to run the build process less often, but we could take that a step further by committing the built files into the repository (while unconventional, at Event Espresso we’ve done this by committing our built JavaScript to our GitHub repository, so even though we use a build process, you don’t need to do any of it to try out our latest work).

- Most importantly, don’t make big decisions with only “Big D” developers present. Their needs are different from the majority. We need to continue to actively gather input from “small d” developers by publishing items for discussion before making a final decision and then being attentive to their input, and talking with them at meetups and in the forums.

Remembering “small d” developers should be a best practice. Because they’re “what got us here”, and without whom we can’t “get there.”

What do you think? Is it important to not leave “small d” developers behind? What can be done?

How I Got All A's on webpagetest.org

https://cmljnelson.blog/2019/02/20/how-i-got-all-as-on-webpagetest-org/ February 20, 2019

2 minute read
I heard about webpagetest.org during my most recent WordCamp. It’s a service for analyzing your website’s performance. From what I can tell, it’s completely supported by sponsors, so it’s free to use.

I ran my WordPress meetup’s site (which, obviously, runs on WordPress) through its analysis, and initially got C grades or so. Not fabulous. But with a little work, I got to all As (well, almost). So I thought I’d share what I did.

[Image removed]

Information about the first pageload on my website. 5 seconds isn’t great, but not terrible. Better than before anyway.

I installed and activated WP Super Cache, and activated “advanced caching.”

Then I updated the “ht access file” (the file next to wp-config.php) with

# Mike attempt to add browser caching
<FilesMatch "\.(gif|png|jpg|jpeg|css|js)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>

Also, I noticed the images I was using were giant. I was using them with the Elementor page builder, which, unfortunately, didn’t give me an option to use the smaller thumbnail versions of them. I got around this by resizing them on my machine and uploading the new version to the website as a different image.

[Image removed]

Graphs from webpagetest.org showing the makeup of the my site’s homepage. Images still what makes the page load at an unimpressive 3s. But not as bad as before.

If I wanted the last A, I just needed to sign up for a CDN. This isn’t a commercial endeavour, so I don’t have any budget, so I didn’t bother with that. I think upgrading my shared hosting would also help with load time.

Anyways, that’s what I did. That’s not what everyone needs to do, and it’s not the only way to improve your webpagetest.org score, but it’s one way.

My 10 Feelings Upon Receiving $20 (for a WordPress Plugin)

https://cmljnelson.blog/2019/02/26/my-10-feelings-upon-receiving-20-for-a-wordpress-plugin/ February 26, 2019

2 minute readThis morning, I received my first financial support for developing the WordPress plugin Print My Blog on Open Collective. Upon seeing the email informing me of that, I’ve had a whole host of feelings… yes, from a donation of $20. Here they are…

Elated

This came first. This was the first ever donation I’ve received. So regardless of its size, I felt unreasonably excited over it.

Embarrassed

It feels a little like winning an award at school or something. I didn’t even want to open the email to see the exact amount.

Justified

The “business model” of the plugin has been this: give away the best product and service I can (in the limited time I have between actual work and family etc) and not charge for anything, just ask people to make donations afterwards if they’re satisfied and want the plugin to be developed further.
Until this moment, I wasn’t sure if it was working. Plugin usage has grown moderately (100 active installs in 3 months), and a few good reviews. but no actual income. So this was a positive change and suggested the idea might have merit.

Hope

This meager $20 filled my head with ideas of making this a sustainable side project.

Nervous

So far the software isn’t too polished. I’ve really only been working on things as users request them, in order to try to wasting time on unused things.
That’s been pretty good, but it means the software isn’t a masterpiece yet. Specifically I worry it won’t work very well with all the thousands of plugins and themes I haven’t tested it with.

Guilt

It’s a little hard to be paid for something you know isn’t “there” yet. I have a long to-do list regarding it.

Greed

Suddenly my head started racing with how to encourage more donations and users etc.

Despair

Then I realized how far away this is from sustainable. In order to have this bring in the income I’d like, it needs about 100 times more donors (each month!) Considering how much work this first $20 was (I’d guess it’s been 20 hours in total, so that’s not a great wage) that doesn’t seem too likely.

Cheap

The platform I’m using, Open Collective, aligns well with my ideas (it encourages transparency in order to encourage donations). But I also realized that it’s fees a rather high: almost 16%. In contrast, PayPal charges about 3%.
So that’s got me thinking “if I get more donations, that 16% will become a pretty big waste”, and wondering how I could save that money. (So I’ve looked into alternatives like Patreon, or self-hosting a website and use GiveWP, or writing my own software from scratch to work with Stripe. My thought right now: just continue with this until donations become more substantial, like 10 times more per month).

Dizzy

Rather than comfort this has brought a dizzying amount of things to consider: expenses, needed features, how to market it better, etc. Phew!

Why Users Should Pay for My WordPress Plugin (Even When it’s Totally Free)

https://cmljnelson.blog/2019/02/26/why-users-should-pay-for-a-wordpress-plugin-even-when-its-totally-free/ February 26, 2019

2 minute readI recently created an Open Collective in order to fund development of my plugin Print My Blog. Here’s its pitch for why the plugin users should elect to donate to the collective. I’m posting here to gather feedback on my ideas, not so to extract money out of people who don’t even use the plugin.

Our purpose is to support Print My Blog, the WordPress plugin to print your blog in 1 click. Use it and your own web browser to create a paper, PDF, or even e-book copy. Preserve your blog in an easy-to-read format. Please see the plugin on WordPress.org
So far, the time/money required to make this plugin been donated by the plugin’s author, Michael Nelson, and a few helpful souls who have reported issues and helped test the software. But that’s not sustainable in the long-term.
Your financial support will help:

- prevent “Print My Blog” from becoming another abandoned plugin (which are, by the way, the biggest security issue for WordPress sites)

- fund new features and improve the software (see GitHub for the current issues and to have your say)

- fund time to help users and manage the project

- help preserve our blogs’ ideas for years to come

- say thanks for the totally free, no-strings-attached, software.

By “totally free, no-strings-attached, software” I mean it’s is free to use and modify and redistribute. And no private data is ever collected about you.
Why? You shouldn’t need to pay for anything silly, including to:

- download the software, as that costs nearly nothing;

- use the software, as your WordPress website can run it fine without any extra costs;

- sign up for a web service to print your content or make PDFs, as your own browser does a good job of that too;

- premium add-ons, as that limits their use, which makes them more buggy;

- support, because ideally you shouldn’t need any, it should just work and be self-explanatory;

- remove ads, because they’re annoying;

- keep your data private, as having big for-profit companies giving things away for “free” should make you wonder;

- or, have a watermark removed, as it actually takes effort to add that watermark in the first place.

However, it does take time/money to:

- design, create, and test the software

- keep the software up-to-date;

- keep the software secure by immediately fixing any security issues noticed;

- answer users questions, and create documentation

- fix integration with WordPress’ ever-changing 50,000+ plugins and 20,000+ themes

- add new features;

- manage the project;

- and, communicate about the project’s status.

And it seems fair to compensate contributors according to the market average for web developers, support agents, copy writers, and project managers. Just because software has no strings attached or arbitrary pay-walls doesn’t mean it should be valued less.
So, supporting the project will help keep it free and useful. But what does supporting the project get you, personally?

- “backers” and “sponsors”-level contributors will get featured on our website (once they help pay for one!) and in blog posts

- “sponsor”-level contributors get a phone call to discuss how to best use the software

- more say in the project

- a good feeling knowing your doing your share.

Thanks if you can! (And if you can’t, a 5-star review would be a great help too!)
If you have questions or comments, please reach out on GitHub, WordPress support forums, or my personal blog.

To Fund WordPress Plugin Development Through Sponsorship, or More Traditional Models?

https://cmljnelson.blog/2019/03/09/to-fund-wordpress-plugin-development-through-sponsorship-or-more-traditional-models/ March 9, 2019

5 minute read
How do you make money when you give your product away for free? It sounds a bit ridiculous, but every WordPress plugin and theme (or any open source project for that matter) faces this exact problem.

It’s led to an epidemic of abandoned WordPress plugins and themes. That’s because they must be free, open-source, GPL software. But it takes real time and money to produce that software, so how can you cover your costs or even make a business of it?

There are lots of attempts to do this, each with a drawback of their own. Let’s survey them:

1. Advertising for Consulting. Give the software away for free, just use it to build your reputation so you’ll get more consulting jobs. Contact Form Clean and Simple is an example of this. But this means the software will forever be a distraction from what actually brings in revenue: consulting. And if you become popular enough, you won’t need the software to build your reputation. So bye-bye software.

2. Pay-to-download. Plugins like MagPress can’t be downloaded for free from WordPress.org, you need to pay to download them from their website. This mostly prevents the software from being used without paying, but it also prevents other developers from contributing to the software (it quickly gets expensive), and means it’s more likely to badly integrate with other plugins and themes. Adding this “pay wall” also slows the software’s adoption by regular users.

3. Freemium. This is where you give away a free version of the software, but also have a “premium” version, or add-ons, that you charge for. We’ve found this to work quite well at Event Espresso. The free version always purposefully withholds some features customers are bound to want, which encourages them to purchase the premium version or add-ons. Sometimes, this leads to grumpy users of the free version because they know you’re withholding features they want purely to get them to pay, and it doesn’t cost you a dime for them to use those extra features. This also has some of the problems of advertising (ie, the free version isn’t your focus) and pay-to-download models (where the premium version or add-ons might not integrate so well with other plugins).

4. Paid Hosted Option. The software is given away for free, like WordPress and Moodle, but there is also a paid hosted option, where you don’t need to install it or maintain it, that’s done for you. The free software gets contributions from its free users, which justifies its existence. But the needs of the self-hosted free users often diverge from the hosted users. Eg, optimizing for speed is always good, but it’s absolutely critical for the users hosted on WordPress.com which receives thousands of visitors every minute, whereas customizability may be a higher priority for self-hosted WordPress users. So the self-hosted and hosted users needs have diverged, and so might their software. This is why WordPress.com runs a significantly different version of WordPress than self-hosted sites do.

5. Pay for Support Only. Download and use the software for free, but pay if you want help using it. This makes the most sense to me, because support is what takes time (and so money). But great software should be well-documented and work fine, and so it’s users shouldn’t need any support. Understandably, they’re grumpy when they need to pay because the software has bugs or the documentation needs work.

6. Pay for Customizations. Like Advertising for Consulting, except you charge for custom code to make the software do something a particular customer wants. But that custom feature wasn’t made before, it’s probably because the majority of users don’t want it. So that work mostly benefits the individual paying for it. So, if it gets included in the next version, it’s actually a hindrance for the majority of users.

So they all have downsides, revolving around two main issues: either the income actually distracts from the main purpose of the software, or the software’s usefulness is purposefully limited.

Funding Through Sponshorships

Enter another idea: give everything away, and ask for sponsorships. A few open source projects are financed this way. If users really want the software to thrive, and know sponsoring it financially is the way to do that, they’ll likely sponsor. Organizations wanting extra exposure to your users are also inclined to sponsor it. This way:

1. The software remains the focus, not unrelated consulting work.

2. There is no pay-wall preventing users from trying the software, or developers from integrating with it.

3. No features need to be purposefully removed in order to sell a premium version.

4. Project maintainers aren’t distracted from the plugin by a hosted version.

5. When there is a bug or someone needs support, you’re not pouring salt on the wound by making them pay extra to get help.

6. The plugin doesn’t get derailed by the feature requests of a wealthy minority.

Does the Math Work?

Now, is supporting plugin development entirely through sponsorship feasible? Surely you will have a smaller percentage of users who pay. But you might have more visitors and users. How do those balance out?

Here are my guesses:

Say 1000 people see your pay-to-download plugin. Maybe 5% of those people will decide to use it, and 90% of those users pay (not 100% because the software is technically free, so users are free to distribute it). So 1000 people x 0.05 x 0.9 = 45 payers.

Let’s compare that to a free plugin. 1000 will probably also see it, and perhaps 40% will decide to use it if paying is optional, probably only 5% will pay it. So 1000 x 0.40 x 0.05 = 20 payers. So probably not great…

But, if the software is free, you’re bound to have a lot more users too. Rather than having users carefully evaluate the Plugin’s features before purchasing, they can just download it and try it. And they’ll probably be happier, because they know you’re not withholding features, or charging them for support in their most frustrating times. So they’re more likely to tell their friends,

So how many more users will there be because it’s free software? Maybe 2x more.

If that’s correct, the sponsorship model will have 40 payers. So one can imagine that it has the possibility of being successful. However, it requires getting a lot more users, because it’s guaranteed a very small percent will decide to pay, when given the option. So I can understand why an established business would be wary to switch.

Summing Up

So far, for my plugin Print My Blog, about 2% of users donating seems to be the trend. I haven’t given it great effort to increasing that percentage yet, so we’ll see if that can be improved. But that’s a baseline number.

It does seem tricky to make a sizable income through sponsorships, but it is easier to make an impact. So if your primarily goal is profit, it probably doesn’t make sense. Whereas if you’re mostly in it to spread the word and have happier users, it’s probably a better fit. I’ll try to share my progress with it.

If anyone has any real numbers they’d like to share from their experience, that would be helpful.

So, are the problems I’ve identified for charging for WordPress plugins accurate? And is funding through optional sponsorship viable?Comments welcome.

Handling Polluted JSON in AJAX

https://cmljnelson.blog/2019/03/25/handling-polluted-json-in-ajax/ March 25, 2019

5 minute read

The bane of all Javascript code using jQuery.ajax() is polluted JSON responses: when some HTML or other junk gets into your JSON response, making it unparsable and bringing the whole system to a screeching halt. In this post, I’ll show what you can do with polluted JSON to keep everything working.

How It’s Supposed to Work

Eg, let’s say you have the following Javascript code

jQuery.ajax(
'https://mysite.com/users/123',
{
success: function(parsed_json) {
alert('Hi ' + parsed_json.name
}
}
);

and it expects a response like:

{     "name": "Mike",     … }

So, when it works properly, the call is made to the server, which responds with the JSON, and then the success callback is called which says “Hi Mike”. [Image removed]

When Things Go Wrong

Now what if there is some other code that echoes something else before your JSON response? Eg

<!-- Here is an HTML comment. Oups! Should I not put HTML comments in a JSON response? My bad!! --> {     "name": "Mike",     … }

This is what I’m calling “polluted JSON”, because the response is no longer parseable JSON, and so the success callback won’t get called. That little bit of extra text in the response just killed your code.

So what to do? The first and most obvious solution, is to remove that pollution server-side. It’s probably there by mistake, so fix that mistake.

But if you don’t control the entire server code, that might not be an option. For example, if you have a WordPress plugin or theme that sends an AJAX request and returns a JSON response, it’s possible another plugin or theme is outputting that pollution. And your users won’t really care who’s fault it is, to them it looks like your code doesn’t work.

Custom Converter to the Rescue

There’s a way to recover. The response in this case isn’t all bad. It’s just that there’s some junk before the JSON that we need to remove.

The way to do that is to provide jQuery.ajax() with a custom converter (documented here, just search for “converters”), that will remove all that pollution, like so:

jQuery.ajax(
'https://mysite.com/users/123',
{
success: function(parsed_json) {
alert('Hi ' + parsed_json.name);
},
// Use a custom converter to remove the pollution from the JSON
converters: {
'text json': function(result) {
// Find the beginning of JSON object or array...
const start_of_json = Math.min(
result.indexOf('{'),
result.indexOf('[')
);
// ...and only send that, skip everything before it.
return jQuery.parseJSON(result.substring(start_of_json));
}
}
}
);

Converters have the job of converting stuff from one format to another. Apparently there are lots of them, but the one we’re interested in is the one that takes the originally plaintext response and interprets it as JSON. Here’s how the code works:

- converters = { tells jQuery we want to register custom converters

- 'text json': function(result) { says we want a new the text-to-json converter

- const start_of_json = Math.min(... looks for the beginning of a JSON object or array (ie, skip over everything before that)

- return jQuery.parseJSON(result.substring(start_of_json)); invokes jQuery’s ordinary JSON parsing function, but only on the JSON part of the response, ignoring all the pollution that came before it

So, even with a response like

<!-- Here is an HTML comment. Oups! Should I not put HTML comments in a JSON response? My bad!! --> {     "name": "Mike",     … }

your code will still work. [Image removed]

A limitation: the above converter assumes the JSON responses will always contain an object or array; and it assumes the earlier “pollution” won’t contain the characters { or [. To overcome that, a slightly more complex solution is needed: you need to recursively check for a substring that is valid JSON. Here is my code that does that:

jQuery.ajax(
'https://mysite.com/users/123',
{
success: function (parsed_json) {
alert('Hi ' + parsed_json.name);
},
// Use a custom converter to remove the pollution from the JSON
converters: {
'text json': function (result) {
let new_result = result;
// Sometimes other plugins echo out junk before the start of the real JSON response.
// So we need to chop off all that extra stuff.
do {
// Find the first spot that could be the beginning of valid JSON...
var start_of_json = Math.min(
new_result.indexOf('{'),
new_result.indexOf('['),
new_result.indexOf('true'),
new_result.indexOf('false'),
new_result.indexOf('"')
);
// Remove everything before it...
new_result = new_result.substring(start_of_json);
try {
// Try to parse it...
let i = jQuery.parseJSON(new_result);
// If that didn't have an error, great. We found valid JSON!
return i;
} catch (error) {
// There was an error parsing that substring. So let's chop off some more and keep hunting for valid JSON.
// Chop off the character that made this look like it could be valid JSON, and then continue iterating...
new_result = new_result.substring(1);
}
} while (start_of_json !== false);
// Never found any valid JSON. Throw the error.
throw "No JSON found in AJAX response using custom JSON parser.";
}
}
}
);

Making WordPress Backbone JS client Handle Polluted JSON

I had this exact problem recently with my WordPress plugin Print My Blog. It loads a regular-ish page, then uses the WordPress REST API Backbone Client to fetch all the posts over AJAX, so that they can all be placed on the same page, so the user can easily print their blog to paper or PDF etc. It works quite surprisingly well- unless some other plugin pollutes the JSON response.

In that case, I needed to jump through one or two more hoops, because I needed to tell Backbone to handle the polluted JSON. Basically, I needed to customize Backbone.sync. Here’s a copy-and-pasteable fix:

var original_backbone_sync;
jQuery(document).ready(function () {
// Override Backbone's jQuery AJAX calls to be tolerant of erroneous text before the start of the JSON.
original_backbone_sync = Backbone.sync;
Backbone.sync = function(method,model,options){
// Change the jQuery AJAX "converters" text-to-json method.
options.converters = {
'text json': function(result) {
let new_result = result;
// Sometimes other plugins echo out junk before the start of the real JSON response.
// So we need to chop off all that extra stuff.
do{
// Find the first spot that could be the beginning of valid JSON...
var start_of_json = Math.min(
new_result.indexOf('{'),
new_result.indexOf('['),
new_result.indexOf('true'),
new_result.indexOf('false'),
new_result.indexOf('"')
);
// Remove everything before it...
new_result = new_result.substring(start_of_json);
try{
// Try to parse it...
let i = jQuery.parseJSON(new_result);
// If that didn't have an error, great. We found valid JSON!
return i;
}catch(error){
// There was an error parsing that substring. So let's chop off some more and keep hunting for valid JSON.
// Chop off the character that made this look like it could be valid JSON, and then continue iterating...
new_result = new_result.substring(1);
}
}while(start_of_json !== false);
// Never found any valid JSON. Throw the error.
throw "No JSON found in AJAX response using custom JSON parser.";
}
};
return original_backbone_sync(method,model,options);
};
});

You can see a lot of the same code reused from before. Here’s some more explanations:

- var original_backbone_sync; creates a variable to store Backbone’s original sync method

- original_backbone_sync = Backbone.sync; stores the original Backbone.sync so we can use it later

- Backbone.sync = function(method,model,options){ creates a new Backbone.sync callback that Backbone will now use instead of its default

- options.converters = {changes the converters object which Backbone passes to jQuery.ajax later. The converter is the exact same as the earlier code snippet.

- return original_backbone_sync(method,model,options); now that we’ve modified the Ajax text-to-json converter, we call the original Backbone.sync method so everything else proceeds as normal.

Here I’m using it my plugin’s Javascript so I don’t need to worry about other plugins having warnings or HTML that breaks my JSON responses. We all just get along fine. [Image removed]

Questions or comments accepted!

The 5 Promises of User-Led Software Development

https://cmljnelson.blog/2019/03/28/the-5-promises-of-lazy-software-development/ March 28, 2019

5 minute readIt’s easy for WordPress plugin developers to be endlessly chasing “modern best practices” and building features they love, but actual users don’t care about. Over the past few months, I’ve been experimenting with a development methodology that avoids waste and stays focused on users’ priorities. I call it “User-Led Software Development” and this is how it works…
As a plugin developer, I promise to:

1. Seek user feedback

2. Only work on users’ top-requested issues

3. Fix every problem in the easiest way possible…

4. then spend no more than equal time tidying up (code, design, automation)…

5. and spend equal time again communicating the change (documenting it, blogging about it, or announcing it).

I originally called it “Lazy Software Development” because it waits until there is a clear need from the users before beginning work (I realized nobody searches for “lazy” so renamed it). It’s just doing the minimum possible, then be attentive to user feedback.

User-Led Development Is Missing…

Notice this does not include any of the following:

- Working in isolation from real users

- Being dismissive of real users’ requests

- Working on whatever the product owner or developer thinks is important (ignoring user input)

- Inventing complicated solutions for simple problems

- Taking ten times longer to build a feature hoping to plan for every possible use-case

- Limitless time for refactoring code to meet elusive “modern best practices” (although it does allot some time for it, equal to however long it took to fix the problem in the first place)

- Skipping documentation (because often in documenting it, you also realize the weaknesses in your product)

- Keeping everything you learned in the process to yourself (because you’re blogging it)

- Keeping secretive about what’s being worked on (so users can give feedback)

- Keeping secretive about what you’re going to work on next or what big ideas you have (instead you should be blogging about it and getting user feedback)

- Sitting back and waiting for user feedback to come (instead, the one thing you need to proactively do is get feedback from users)

The Results

This seems to be working pretty well for my small plugin, Print My Blog (small both in terms of users, 200, and codebase, just a few dozen files). There’s plenty of areas for improvement, but I put links everywhere telling users to ask for support. And when they do, I see what really matters, not what I just thought would matter.
And far from being upset, users who report the issues are usually really happy. That’s because I’m free to be really responsive to their feedback (instead of being focused on what I thought mattered).

User-Led Development in Practice

I began my plugin with promise 1: “seek user feedback”. I wrote a blog post describing how our blogs will probably inaccessible in 50 years, and described what I thought would be a good solution. It got reblogged by a friend, and her readers almost unanimously wanted a different, simpler. solution. So had I built what I thought people would want, I highly doubt it would even have 200 active installs today.
So then I began promise 2 “Only work on users’ top-requested tasks”. They wanted a really simple way to print their entire blog. Even though I had a hundred features in mind, I just focused on that top priority.
So I built it “in the easiest way possible” by throwing some JavaScript together that used the WP API to fetch all the site’s posts and dump them onto the page, and then users could print that page from their browsers. (I didn’t try to screen scrape their content, or create multiple file formats server-side etc. Those might have been better, but certainly would have slowed down the initial release). It had no options, and a really basic interface, but it did what they wanted: made printing their entire blog easy.
Then, once I had it built and uploaded to WordPress.org’s plugin repository, I blogged about it and why I think every blogger on WordPress should use it to backup their blog to a low-tech format. In the process of doing that, it got noticed. And it started to get downloaded.
So that was my first pass through the 5 promises of lazy development.
Pretty soon I was getting bug reports and folks wanting new features. And rather than ignore them (and get a bad review in the process), I used their feedback to guide development. I added support for pages (I had erroneously thought no one would want to print pages), categories and tags, and comments. None of those was added in a really pretty manner, but that was ok because it served those users needs. I’m pretty sure I’ll need to beef up that code in the future (actually, some of it I have already), but for now it made people happy and got the plugin some positive reviews. And if no one ever notices those features were slapped together, then they’re fine as-is, and there is no need to waste any more time on them.

Objections, Anyone?

What problems could there be with user-led development?

Security

Is it ok to be lazy when it comes to security? Eg would I advocate for “I’ll only add a nonce check if there is a reported security breach”? This is subjective and up to personal preferences. But I’d say you should be much less lazy when it comes to security.

Big Ticket Tasks

Now what about big ticket jobs, like introducing automated testing, or reducing file sizes, or updating code to use latest coding standards? Perhaps an exception could be made, but generally I would include that in the “tidying up” time. What if you’re unable to finish those in that time? Do another top-priority item, and use that tidy-up time for it again. But the point is: unless they are deemed necessary to get the job done, they have a limit on how long they can take.

You Never Get to Work on What You Want

Yes, it could appear you’d never get to work on the features you think are exciting… but there’s a loophole: you can be a user of your own plugin. If you’re actually using it as intended (not just on a test site, but on a live site) then you’re a user too, and I think you get to request features. Actually, far from being a loophole, I think using your own software is essential. Without it, you end wasting a lot of time on unused features and don’t realize users pain points.

This Won’t Work for Large Projects

That may be correct. To my mind, I’ve verified this works for a small project, but no, I’m not certain it will work for bigger ones. But the idea of release early is hardly new.

If you want to know the truth about what you’ve built, you have to ship it.

We do the best job we know how to do and then we launch it into the market. The market will tell us the truth.

“It Doesn’t Have To be Crazy at Work” by Fried, Jason; Hansson and David Heinemeier

What’s your feedback?

Gotcha! In the process of reading this, you’ve become my “users” who will give me feedback on “user-led software development”! (Ie, please share your thoughts in the comments.) But even if you don’t, that’s also a form of feedback: what I’m saying is either out-to-lunch or not that noteworthy. So either way, I’ve received feedback.
But it would be nice to chat about it. Thanks!
(FYI the cover image is by my 5-year-old. It’s totally unrelated to the topic, but has a fabulous attitude about it, and I thought the world needed to see it.)

Print My Blog Transparency Reports – November 2018 to March 2019

https://cmljnelson.blog/2019/03/29/print-my-blog-transparency-reports-imported/ March 29, 2019

5 minute read
I used to make my transparency on plugin development reports right in Open Collective, but I really prefer to keep them on my blog, like I outlined last time. So here’s all my old reports compounded into one blog post.

Reports From Open Collective

1.6.3, updated WordPress.org description, and comments feedback

published on March 29, 2019

This week was fairly quiet.

I noticed https://deadeasyfamilyhistory.org/print-my-blog wasn’t working for wordpress.com sites yesterday. It was because of an error I introduced in version 1.6.0. I managed to fix it fairly promptly though, so we’re back-in-business. (All self-hosted users wouldn’t have been affected).

In the process, I made a few changes to the plugin description on WordPress.org. I made the first two paragraphs much more succinct and easier on the eyes. (I realized this change was necessary because when I showed it to my brother, he basically got halfway through reading the first paragraph, then skimmed the rest… I suspect many other people do the same!) Unfortunately that broke the German translation [Image removed] .

Lastly, I got some valuable feedback from Leac on https://wordpress.org/support/topic/option-to-print-comments-too/ about how comments are displayed in the plugin. But I’m going to wait further feedback before making a move on those items.

Also, I blogged about plugin development methodology: “The 5 Promises of Lazy Software Development” https://cmljnelson.blog/2019/03/28/the-5-promises-of-lazy-software-development/

Stats this week:

- 200+ active installs

- 2,228 downloads (+250 or so)

- 7 five-star reviews

- $17 annual donations

- 2 languages

1.6 adds filtering by category, readme update, and translated into German

published on March 22, 2019

This week I released the work from previous weeks (which added filtering by categories and terms; foogallery support; handling polluted JSON) in 1.6.

I also updated the plugin’s description on wordpress.org (the “readme.txt file”). It first points out the uses of the plugin, then lets users know it’s supported by donations, then lists features, gives a few use-cases, and even mentions alternative tools. I made the change because I don’t want it to be a surprise that I’m looking for sponsors, and thought it could be better structured.

Also, I noticed just today that Harald Wenzel (https://twitter.com/Epiphanius1) entirely translated the plugin into German. Woot! That’s the first translation of the plugin.

Lastly, there was some bad news: a report this week that it caused so many requests on a site that it caused it to totally go down: https://wordpress.org/support/topic/author-filter-5/. I’ve followed up trying to find out more, because right now I’m in the dark about how it happened, and what can be done to avoid it in the future. If anyone else experiences this please work with me to identify the cause and find a fix so we can prevent this in the future.

There was also a request for the ability to filter by authors (first time that’s been requested; so it’s been logged but not sure if I’ll make that change right away).

Stats this week:

- 200+ active installs

- 2,017 downloads (+300 or so)

- 7 five-star reviews (+1)

- $17 annual donations

- 2 languages (+German)

More foogallery support, filtering, and handling polluted JSON

published on March 15, 2019

This week I:

- opened an issue asking FooGallery team about how to make sure dynamic images load without needing to scroll all the way down the page. They responded very quickly and investigated the issue, but didn’t come up with a solution

- am getting the filtering posts by categories ready. The taxonomies available for filtering now also takes into account what post type you’re printing (posts or pages; and should work once custom post type support is added too)

- figured out how to get Print My Blog to work even when other plugins accidentally add warnings or junk text to the REST API responses. See this commit if you’re interested.

The version to test is https://github.com/mnelson4/printmyblog/archive/BUG/foogallery-support.zip

Stats this week:

- 200+ active installs (last week it was 100+)

- 1,751 downloads

- 6 five-star reviews

- $17 annually in sponsorships (I have some ideas on how to improve this, but trying to first resolve those code issues mentioned above)

Filtering by categories. & debugging h foogallery and WPTouch

published on March 15, 2019 (intended for March 8, 2019)

Oups, this should have been published last week. (Wish I could retrodate it like with WordPress…)

This week, I’ve been working on:

- Filtering by categories

- Helping debug an issue when Print My Blog was used on http://siliconvalley.sla1.org/, possibly caused by the plugin WPTouch

- Debug why foo gallery doesn’t appear in printouts

If anyone is able to test the upcoming version (which supports filtering posts by category) it can be downloaded here: https://github.com/mnelson4/printmyblog/archive/FET/filter-by-category.zip

First donation; 1.5.0; all post content is now optional; post IDs and dividers added

published on March 1, 2019

Print My Blog received its first donation this week! I blogged about that here on my personal blog. So thanks Dan and Furniture Bank (who also found an unexpected use for the plugin).

And I forgot to mention last week, J. Di Goia probably set a new record for the biggest printout using Print My Blog: 3145 posts!

What’s New

As of 1.5.0, all parts of the post can be removed, so you have more control over what gets into the printout.

Just want post titles, post URLs, and the excerpt? You can do that. Or do you want the full post content, with ID, URL, featured image, comments, and a divider at the end? You can get that instead.

Here’s a screenshot:

[Image removed]

New, More Compact, Layout for Print Content Options

Oh, and you can now also include the post’s ID, URL, and an extra divider (to further help delineate between posts, which can be hard for posts with lots of big images).

Filtering posts by date or category is the next big ticket feature. See GitHub issue 6.

Also, other plugins’ shortcodes often go un-rendered (see GitHub issues 12 and 9), usually because they require Javascript that can’t be retrieved over the REST API (which is how we’re fetching all the posts). I created a WordPress core issue to begin to explore how this can be addressed.

Comments support, Show Post URLS and Enfold theme compatibility

published on February 22, 2019

This past week I spent 2 hours in forums/email answering some questions, and 3 hours developing and releasing some new features:

- optionally showing post comments in printout (see https://wordpress.org/support/topic/option-to-print-comments-too/) which became version 1.4.0

- Enfold theme compatibility (got contacted directly from my blog about it not working with this theme. I couldn’t quite reproduce the issue, but took a guess and got lucky on how to fix it!)

- optionally show post/page URLs in printout (again, simple feature request directly from my blog)

Next main feature planned: filtering so you can only print posts in specific categories or date ranges (see https://wordpress.org/support/topic/feature-request-print-posts-in-specific-category-or-tag/)

Filled in Description

published on February 14, 2019

I finally just filled in the description of this collective. It took about an hour and a half, but it was probably good to work through it.

Older Personal Notes

Here’s a few older notes I jotted down about the plugin’s earlier progress, which may be interesting…

March 15, 2019

200 users, 1700 downloads, 6 5-star

Jan 11, 2019

50 users, 417 downloads, 3 5-star reviews.

Dec 2019

20 users (7 my own sites), 100 downloads, 2 5-star reviews. Probably 12 hours this month

Nov 2019

1 user, 30ish downloads. 1 5-star review (mine)
It took about 8 hours to get it here, so that it’s usable and published on WordPress.org.

Immortalize Your Blog by Turning It into a Family Search Memory

https://cmljnelson.blog/2019/04/02/immortalize-your-blog-by-turning-it-into-a-family-search-memory/ April 2, 2019

6 minute read
So you have a blog to share your stories with friends, family, and the world. Great. But will it still exist in 50 years? How about 100? Most likely it will fall victim to the “Digital Dark Age“, and won’t be available. Your grandfather’s memoirs written on paper might be more accessible than your blog. And if your stories are worth sharing with future generations, that’s a shame.

In this post, I’ll show how to make your WordPress blog’s stories available to future generations using Family Search Memories and the WordPress plugin Print My Blog.

Recently I created a WordPress plugin for helping to print your blog to paper or PDF, in the hopes of preserving it. Today I’m going to build on that by showing how you can send that PDF-version-of-your-blog to Family Search in order to make it available to future generations.

Why Family Search?

Family Search is the largest genealogical organization in the world, and has existed since the latest 1800s. It “gathers, preserves, and shares genealogical records worldwide”, all for free. Also importantly: it’s actually operated and financed by the Church of Jesus Christ of Latter-Day Saints, so they’re religiously dedicated to preserving family history data.

Family Search also realizes that today’s news will be tomorrow’s family history, so they’re interested in preserving current information. They encourage users to upload current family photos, stories, and documents, so future generations can have them. So if your blog will be of value to your family in the future, it’s a great thing to store as a Family Search Memory.

Should My Blog Become a Family Search Memory?

Of course, not all blogs will have historical value. Eg, if your blog is technology tutorials or restaurant reviews, it’s debatable whether it will have “historical value.”

In their upload guidelines, Family Search outlines the general criteria for content on their service:

Appropriate. Content should support appropriate standards of modesty and virtue.

Relevant. Content should support a family history purpose.

Heart-turning. Content should support individuals coming to know and love their ancestors.

Noncommercial. Content should not advertise or promote products. They should not infringe on intellectual property rights.

Family Search Upload Guidelines and Policies

You should read over Family Search Upload Guidelines and Policies for the most up-to-date information.

Prepare Your Blog’s Stories with Print My BloG

If you think your blog meets Family Search’s requirements, it’s time to get your blog into a format that can be uploaded to Family Search. Specifically, we want to create a PDF.

If your blog is a self-hosted WordPress blog, you can use the free WordPress plugin Print My Blog. If your blog is hosted by WordPress.com, you can use a hosted version of it on DeadEasyFamilyHistory.org.

If your blog isn’t run on WordPress, you may be able to use another service to create a PDF from your blog. I would suggest trying bloxp (also free) or one of the paid services out there.

But it’s important to realize two additional technical requirements for Family Search Memories:

1. The PDF must be under 15 MB in size. That means you’ll probably need to exclude images from the PDF.

2. They require there be no hyperlinks in the PDF. So we’ll use Print My Blog to automatically remove those (if you’re using something else, you may need to manually remove them).

But for the purpose of this tutorial, I’ll be using Print My Blog and Google Chrome web browser. Here’s the steps:

1. Install and Activate Print My Blog

Install and Activate Print My Blog plugin from your WordPress Dashboard. To do that,
1. Under “Plugins”, click “Add New”.
2.Search for “Print My Blog”
3. Click “Install Now” (next to “Print My Blog”), then “Activate”.

If You’re on WordPress.com: Just go to deadeasyfamilyhistory.org/print-my-blog.

Link of the removed image [Image removed]

2. Configure the Printout

After that, you’ll be taken to the page where you setup Print My Blog.
Click “Show Options”, then select a category of posts that you’d like to include. If you want to include all posts, leave it blank. Then:
uncheck “Featured Image”, uncheck “Show Printout Meta Info”, (optionally) set “Columns” to 2 or 3, set “Image Size” to “None”, and set “Include Hyperlinks” to “Remove”.

Then click “Prepare Print Page”.

Link of the removed image [Image removed]

3. Wait and Click “Print”

It may take a few minutes, but soon you’ll see “Print-Page Ready” and the button “Print” underneath it. Click “Print”.

Link of the removed image [Image removed]

4. Save as PDF

This is Google Chrome’s print screen. Remember to set “Destination” to “Save as PDF” in order to save a PDF instead of printing to paper. And then remember where you saved the file, you’ll need it in a second.
On other browsers, the way to print to PDF will be different. Please Google “How to print to PDF on {name-of-browser}”.

Link of the removed image [Image removed]

Once you’ve gotten your hands on a PDF of your blog, it’s time to upload it to Family Search.

5. Log Into Family Search

Go to familysearch.org, and sign in (or create an account if you’re new, it’s free).

Link of the removed image [Image removed]

6. Upload the PDF

After you’ve logged in, click on “Memories” at the top.

Link of the removed image [Image removed]

Next, click “Add Memories.”

Link of the removed image [Image removed]

From there, click the big green plus button. When you hover over it, it will again say “Add Memories.”

Link of the removed image [Image removed]

Click “Choose Files”, and select the PDF of your blog.

Link of the removed image [Image removed]

Select the PDF of your blog.

Link of the removed image [Image removed]

Notice a new item has appeared. Click “AddTitle” and give it a name (like “Mike Nelson’s Blog”) then press “enter” on you keyboard. Then “Add Tag.”

Link of the removed image [Image removed]

Click “Who is in the memory?” and enter the names of you and anyone else mentioned in your blog (you may need to create people in Family Search for that.)

Also, click “Add” under “Description” to describe the file (keeping in mind it might be read in several decades from now, so being descriptive is good.)

Link of the removed image [Image removed]

Then you’re done! Family Search will take a day or two to review your submission before it’s official. They have a review process which can sometimes erroneously flag material as inappropriate. In that case you just need to e-mail them explaining why your submission meets their upload guidelines.

How Will Others Access Your Blog on Family Search

If you only tag yourself in the memory, currently only you will be able to see it. However, when you pass on (or are 100 years old) other Family Search users will be able to see your Family Search details and easily find your memories.

However, if you tag deceased family members in the memory, other Family Search users will be able to see those individuals details (it’s a shared family tree, afterall), and their associated memories, like your blog memory.

Go Immortalize your Blog!

I hope this gives you a good idea of how to can convert your blog into a PDF file that can be uploaded to Family Search, so it will be available in the coming years (long after your actual blog is probably taken down).

On behalf of future generations that are interested to hear your blog’s stories, thanks for taking the time to do this.

Please feel free to comment or ask questions below.

(The cover photo was from Unsplash.com, by Laura Fuhrman)

Why We don’t Donate to WordPress Plugins, Even When We Know We Should

https://cmljnelson.blog/2019/04/23/why-i-dont-donate-to-wordpress-plugins-even-when-i-know-i-should/ April 23, 2019

10 minute readHave you ever been on a WordPress.org plugin page, and seen a link saying “Donate to this plugin”? You probably didn’t click it. Nearly none of us do. But why not? You probably think you should, but something is preventing you. In this article, I explore the reasons we rarely donate to software we depend on, and what can be done about it.
I recently had the hair-brained idea to fund development of a WordPress plugin entirely by donations. By that, I mean don’t explicitly require payment for anything, just ask users of the software to voluntarily sponsor it financially, and through that receive a sustainable income.
Others have had similar ideas, and the prognosis isn’t great. It absolutely goes against conventional business wisdom. But somehow I believe it’s possible. If there is any chance in overcoming the difficulties this presents, I should first identify those difficulties. So here we go…

I Haven’t Donated to Any Free Software Myself, So Why Should I Expect Others To?

That’s right, I can’t recall ever donating money to another plugin or for any other software, or nearly anything. So it’s an obvious double standard to expect others to donate to me.
But thinking of it some more, there are a few things I’ve voluntarily donated to.

- Shawnigan Residents Association (local community advocacy group),

- Toonie Tots (play gym for preschool children, which just operates on the honor system),

- Ocean Discovery Centre (kinda a mini museum in nearby Cowichan Bay that has a suggested donation)

- local apples and eggs (also operate on the honor system)

- tips at restaurants, that’s also a donation

- Oh and 10% at church, plus another monthly “fast offering” which is only suggested to be the value of two meals.

Also, I certainly do many donations in kind online:

- contributing code to WordPress core and plugins and themes,

- giving them 5-star reviews etc, and

- helping a few people out in the local WordPress meetup and WordPress support forums.

So on second thought, there are a few things I donate to after all. But admittedly, most of them aren’t digital, and if they are, they’re probably just non-monetary.

Take Away

So, in order to figure out how to get others to donate actual money for something digital, I should also figure out what exactly is preventing me from doing the same. I explore this more throughout the rest of this post.

I Don’t Have Spare Money To Donate

I think this will probably be the most common excuse, and I think it’s totally bogus. A $5 annual donation to Wikipedia is nothing. It’s the cost of the gasoline for a 20 minute drive, which most of us never think about. Yet if even 3% of Wikipedia users gave $5, they’d have money to spare (it at least that’s what their pop-up said).
The point is: even if everyone donated 0.1% of their income (eg $50 of $50,000 annually) to free software, they wouldn’t even notice the loss, but all those free software projects would be sustainably funded.
Eg, my obscure Print My Blog Plugin, with a mere 300 active installs, could have a budget of $15,000 annually if all it’s users donated 0.1% of their annual income to it. Not enough to live off yet, but it would more than cover my opportunity cost in developing it. In contrast, it’s budget for the year is currently $17.

Take Away

We need to help potential donors to realize “I don’t have money to donate” is just an excuse. There may very well be other valid reasons to not donate, bit this is not one.

People Allocate Very Little Money to Making Donations

We’ve been teaching our 5 year old about budgeting, and she has a piggy bank with 3 sections: save (50% is meant to go in that), spend (40%), and share (10%) .

[Image removed]

I think us adults similarly have our income divided up. We would, of course, also have a really big fourth section labeled “necessary expenses”, probably taking up between 40%-90%. Regardless, I bet 10% for sharing is unusually high.
Money to pay for a premium plugin up-front comes from our “necessary expenses” pile: the pile for housing, transportation, food, clothing, website hosting , website plugins, etc.
In contrast, money to donate to a plugin after we’ve already used it most likely comes from our “share” pile: the pile for nacho chips, lottery ticket, weekend getaway, donating to a plugin.
And if we’re talking about business expenses, there’s an even bigger difference. Expenses get taxed differently than voluntary donations.
So what I’m saying is that just by renaming the expense, the funds gets withdrawn from a much smaller pile: the tiny “share” pile, where money is really tight, instead of the big “necessary expenses” pile, where we mostly spend without thinking because they’re “necessary”.
Take Away

So, I’ll probably get more donations if I can help people view it as a “necessary expense” rather than just “sharing.”
And better yet: if I can help people claim it as a business expense, there should be more donations. (FYI that one benefit of Open Collective: facilitate giving donors a receipt for their donations.)

Awareness

I’m often surprised to discover someone would like donations for something. Like HeidiSQL, WordPress Foundation, Mozilla Firefox, and Webpack. They all operate on donations, but I didn’t realize that until months or years of benefiting from them.
Because payment isn’t required before usage, it often gets skimmed over or skipped altogether.

[Image removed]

See the plugin donation link? Many plugins have them. But they’re white buried away, only slightly higher than the link to WordPress.com and Matt’s Blog.

Many WordPress plugins also accept donations, and have a link right on their WordPress.org page, but it’s a little bit buried, and so often goes unnoticed.
Take Away

In order to get donations, people need to at least know you’re looking for them.

WordPress.org Plugin Guidelines

The WordPress.org plugin guidelines are accommodating to plugins with paid add-ons (including having advertising for them in the free plugin), and using plugins to boost a consulting business, and JetPack, but might be a bit non-conducive to promoting donations. The guidelines say you should avoid

Compensating, misleading, pressuring, extorting, or blackmailing others for reviews or support (donations)

Of course I won’t be misleading, extorting, or blackmailing. Compensation and pressuring are up for debate though…
People who donate will be compensated with public recognition for it. But the guidelines probably view this type of compensation as reasonable, as opposed to direct monetary compensation (eg save 50% on swag if you give us a 5 star review), or in-app bonuses (eg “to unlock this feature, make a donation”). But simple recognition that a donation was made is following how WordCamps and meet-ups do it: if you donate, your donation will be announced, and your logo will be associated with the event. The compensation I’m wanting to give donors is the same.
And is it “pressuring” if you say something like “Help keep this plugin maintained by donating”? There is obvious pressure, because you’re implying the consequence of everyone not donating is that the plugin will not be maintained. But I’m not sure if it’s unreasonable pressure. It seems quite reasonable to make users aware of the costs to maintain the plugin, and the natural consequences of not contributing. (The WordPress plugin repository is ripe with plugins whose author have no real incentive to maintain them, and so get abandoned. The consequences are real, but explicitly pointing them out could be labelled “pressuring.”)

Take Away

So, you just need to be careful that the compensation and pressure to donate be kept within the subjective realm of “reasonable.”

Selfishness

Our initial inclination is usually to selfishness, unless we actively try to avoid it. Plugin users (and everyone for that matter) default to taking all they can (free software, free support) and give nothing back.
Of course, given a long term look, they’d realize it’s in their long-term benefit to help maintain the software that was so useful to them…

Take Away

You should try to invoke users’ proactive, unselfish nature’s; or at least help them realize that if they find the plugin is of benefit to them, it’s in their best interest to help maintain it.

Laziness

I’m actually a big fan of being lazy (I like lazy code and lazy feature development, because both avoid waste) and it’s reasonable for us to not do something until it’s urgent.
Even if someone wants to donate, it takes time and effort to sign up for a service like Open Collective, type out your billing info, and make a donation. And if it’s not urgent, so users might wait to do so indefinitely.

Take Away

You need to somehow convey some urgency (while not venturing into the realm of “pressuring”, like mentioned in the WordPress plugin guidelines.) maybe telling users the price of donation tiers will go up soon? Or that features will only be added once there is budget for them?

“Somebody Else Will Finance It”

“The tragedy of the commons” applies here for sure: it’s in the collective best interest of all plugin users to have it well-maintained, but it’s also in their individual best interest to wait for someone else to fit the bill. So what happens? Even though everybody wants it to be supported, nobody does.

Take Away

You need to somehow incentivize individuals so that it’s in their individual best-interest to support the plugin, not just the collective best interest. Or, if Sally donates, there is a benefit only Sally receives- John’s donation won’t give this benefit to Sally, so she can’t wait for him to donate in order to get the benefit.

Accustomed to free services making hidden income

There are lots of free services online. I’ve been using Gmail for years and haven’t spent a dime on it. Nor have I needed to wonder “how are they making ends meet?” I just use it and that’s that.
So it is with most of us. We get our immediate needs fulfilled (eg, need an email account) so once we have it (through Gmail) we never think about the needs of others (that Gmail needs to turn a profit, at least indirectly, in order for it to continue to exist.)
Of course, upon further inspection we discover that these “free” services have unexpected costs. Eg

if you’re not paying for something, you’re not the customer; you’re the product being sold

is a quote that’s been floating around lately, meaning, if you’re getting a service for free, the company that’s giving the service is probably selling data about you to advertisers, or are selling space to advertise to you, etc. (It’s not entirely true, of course companies that charge you money do this too.)
My plan features having no such hidden ways of making money. I want my focus to be on making the plugin as good as possible, and so be compensated for just that. I don’t want the plugin to be a lure that wets users appetites, and from there sell them something else (because then the plugin isn’t the focus.)

Take Away

You need to try to bring the fact that there’s no hidden agenda to users’ attentions so they’ll appreciate it, and be more appreciative of it.

Defy’s Expectations

I recently signed up on Medium.com and was using it for free, only to soon learn I needed to pay $5 per month to continue using it. I didn’t really like that, but I started wondering what exactly it was that I disliked about it so much… especially when I’m paying over $100 every week at the grocery store, and don’t begrudge that, nor my monthly hosting bill, or other paid services. So why can’t Medium charge me $5 to use their service?
It’s not that I don’t value it $5. I think it’s just that it was a surprise expense. I expected it to be free (no mention of price was made when I signed up, and I assumed they made their money through advertising like everybody else) and when that wasn’t the case it felt like a “bait-and-switch”.
Users of my plugin could easily feel the same: they assumed my plugin was financed by somebody else (like how Anthologize was financed by a college, or WooCommerce is financed through selling add-ons, or Contact Form 7 is basically advertising for the developer’s consulting business). So they feel surprised when I suggest they make donations to keep it afloat.

Take Away

You should make it explicit from the get-go that the plugin is funded entirely through donations. So after they’ve tried it, and decided it’s useful, they should then seriously consider making a donation.

You’re still Still selling

While I’m not selling access to download or use the plugin (because those are both totally free), I am kinda still selling something: the idea that they should make a donation.
Everywhere I see folks asking for donations in a really weak, unconvincing manner. It’s usually just a brief call-out: “Donate now!” Or “buy me a coffee!” Easily ignored.
It’s incorrect to assume that just because people find software indispensable, that they’ll therefore logically donate to it (ask the developers of OpenSSL, which secures two thirds of the internet and yet was developed by a handful of developers, mostly in their spare time). They’re convinced of the software’s usefulness, but not the idea of donating to it. They still need to be “sold” on that.

Take Away

The invitation to donate needs to be convincing. If you want the project to be sustainable, it’s unfortunately not enough to just make great free software that becomes popular. You still need to sell the idea that it merits donations.

It’s Hard to Pay for Immaterial  Services

I don’t think it’s a coincidence so many online services sell merchandise. We have it ingrained in our culture that usually you pay for physical things, but immaterial things are usually free. Eg, you pay for the groceries, but not for the time of the cashiers or baggers (although in Mexico, they always tip their grocery baggers.)
Changing this part of our culture is very hard. But a good first step is creating awareness.

Take Away

If possible, compensate donors with something more tangible. Maybe a phone call, consulting time, or a shout-out on social media. Or somehow give them a physical good.

Anonymity

Plugin users usually stay anonymous, and so there’s no fear of being called out as a free rider. I think most cases where I’ve voluntarily donated it was partially because of social pressure to donate. But there is no social pressure if you’re anonymous.
Imagine if there was a public list of users of a plugin. You would see how many Fortune 500 companies are free-riding on your plugin. There would probably be a lot more donations because they’d fear being called out as a free rider.
I doubt this situation will change (especially because when a plugin is discovered to have a security bug, the exploiters would love having a list of potential victims). Nevertheless, I think this is a major hurdle to plugins receiving donations.

Take Away

Try to get to know your users, and they won’t be anonymous anymore. This has the added benefit of helping you get to know their actual needs, and encourages user-led development.

Phew! Is That It?

That was literally all the reasons I can think of why I don’t donate to WordPress plugins I use… plugins like User Switching, User Role Editor, and Contact Form 7. Indispensable plugins, just I’ve never donated to them (I did, however, finally give each of them a 5-star review while writing this).
What do you think? Why don’t you donate to plugins (or any free software) you find indispensable? What could be done to change that?
Thanks for sharing!

Print my Blog Plugin Transparency Report – April 2019

https://cmljnelson.blog/2019/05/07/print-my-blog-plugin-transparency-report-french-ssrf-fix-improved-json-parsing/ May 7, 2019

9 minute read
This is the first of monthly transparency reports about development of the plugin Print My Blog. I want to:

- Share my experience developing a WordPress plugin so others can learn from it

- Remember what actually happened for my own records

- Inform users and potential sponsors of the open collective how donations are being used and where things are headed

- Create more awareness about the plugin itself (as I understand it that’s one potential benefit of transparency reports: you give away a bunch of interesting information, normally kept secret, and in exchange you get noticed more)

- Get feedback on my sometimes outlandish ideas!

(Previously I did a weekly post on my blog, and on open collective.)

What Happened in April 2019

- Hours:

- 13 (+2.5) support

- 15.5 (+4.5) copy writing

- 44.5 (+10) development

- 6.5 (+1) management

- Expenses: $2839.21 (+$661.50 )

- Donations: $20 (+$0)

- Downloads: 3,549 (+1,200)

- Active Installs: 300 (+100)

- Languages: 2 (+0)

- Five Star Reviews: 10 (+3)

- Releases: 22 (+5)

Overview of What’s New

- Plugin Translated into French, (but needs a French Translation Editor’s approval)

- Security issue discovered and patched

- Plugin compatibility improvements

- Content Marketing:

- Last Weekly Report

- Imported Old Open Collective Reports

- Why We Don’t Donate to WordPress Plugins, Even When we Know we Should

- Immortalize Your Blog by Turning It Into a Family Search Memory

The Details

French Translation

I tried my hand at translating the plugin into French, but it still needs a WordPress French Translations Editor to approve the translations… If you are, or know, an editor please help out with the French translation of Print My Blog.

The plugin doesn’t have a ton of text, but still it took about 3 hours to translate it all. It was probably a good exercise because:

- It may open up the plugin to discovery and use by a whole new segment of users

- It gave me a better appreciation for how much effort it takes to translate a plugin

- I noticed several typos along the way! [Image removed]

The Plugin’s First Security Issue: SSRF

I got contacted late last week by a penetration tester named
Magnus K. Stubman, via my blog’s contact form, saying:

[Image removed]

Hi, I’ve found a security issue in one of your plugins. Reach back to me at xxxxx if you’re interested in the details. If I don’t hear back from you within 5 days, I’ll assume it’s OK with you that I publicly disclose the issue.

[Image removed] [Image removed]

I was a little worried it was a phishing attempt, but the sender seemed legitimate.

So I replied and he pointed to an “unauthenticated SSRF that can be turned into XSS.” …I had to ask DuckDuckGo what that meant…

SSRF stands for “Server Side Request Forgery“, meaning a hacker can make the server send a request to something the hacker normally can’t. The quintessential example of this is getting the server to send a request to get something normally hidden on the server (like WordPress’ passwords in wp-config.php) and then return them to the hacker.

In the case of Print My Blog, in order for it to print a different WordPress blog like on deadeasyfamilyhistory.org, users could input a site to print. When they did that, we’d send a request to that site to check it was a real WordPress site. And that’s where there was an SSRF vulnerability.

The fix was to just disable that feature, because most users of Print My Blog just want to print their own site, not be a service for printing other sites like Dead Easy.

After giving me time to fix the issue, Magnus disclosed the issue on his blog, and reported it to the vulnerabilities database cve.mitre.org.

[Image removed]

Magnus’s blog, he’s a penetration tester, gentleman, and ASCII artist

In this specific case, I’m still not too sure how a hacker could exploit it. They can make older versions of Print My Blog send an HTTP GET request to any URL as the site owner, but they can’t see the result of that request. I think they would also need to find some site (behind the same firewall as the server running Print My Blog) where just receiving a request would change something normally prohibited (like creating a new blog post or user.) So, it’s clear the security bug had potential to be a definite concern, but it would take a bit more know-how than what I have to exploit it.

Oh and in a side note, the discovery of this security issue led me to invest a little more time in looking for other security problems. I signed up for coderisk.com. It automatically checks your plugin’s code for security issues. It was quite a good experience so far, and it did find another security issue which got patched in 1.6.8.

WP Engine and Print My Blog

Also interestingly, Anthony from WP Engine also contacted me about the security issue (this was actually kinda cool, it means they took notice of my hobby project!) He also used my blog’s contact form (glad I have it! It allows anyone to reach me privately without giving out my email address publicly). He said WP Engine have site owners using Print My Blog, but they’d be encouraging them to update .

I said thanks for that, and brazenly suggested they sponsor the plugin too.

Thanks Anthony! No questions. Except “Would WPEngine like to sponsor the plugin?” [Image removed] It’ll get your logo in front of about 300 site owners (many of whom are closing their site’s down, hence why they’re printing their site, and possibly looking for new hosting) for $25/month. See https://opencollective.com/print-my-blog#about

Either way, thanks for reaching out!

Anthony said he’d pass the info on to their Affiliate team. (It’s a long shot, but if I don’t ask the answer will definitely be “no”.)

Improved JSON Parsing

Also this month the plugin got its first non-5-star review [Image removed] .   Print My Blog wasn’t working on the user’s server, and they thought it was because the site was in Greek.

I investigated the issue and saw a Javascript error relating to Google Recaptcha originating in some Contact Form 7 code, but it turned out to be a red herring (because even if there’s a fatal error in Javascript, code from other Javascript other threads will continue to work fine… so in this case, a fatal Javascript error isn’t so fatal afterall!)

Finally, I noticed the error was from the CataBlog plugin sometimes dumping some script tags into WP REST API JSON responses, like so:

<!-- CataBlog 1.6.7 LightBox JavaScript | http://catablog.illproductions.com/ -->
var js_i18n=new Object; js_i18n.prev_tip="You may also press "P" or the left arrow on your keyboard"; js_i18n.next_tip="You may also press "N" or the right arrow on your keyboard"; js_i18n.close_tip='Close LightBox Now'; js_i18n.prev_label='PREV'; js_i18n.next_label='NEXT'; js_i18n.close_label='CLOSE'; jQuery(document).ready(function(){ jQuery('.catablog-image').catablogLightbox(); });
<!-- End CataBlog LightBox JavaScript -->

<!-- CataBlog 1.6.7 LightBox JavaScript | http://catablog.illproductions.com/ -->
var js_i18n=new Object; js_i18n.prev_tip="You may also press "P" or the left arrow on your keyboard"; js_i18n.next_tip="You may also press "N" or the right arrow on your keyboard"; js_i18n.close_tip='Close LightBox Now'; js_i18n.prev_label='PREV'; js_i18n.next_label='NEXT'; js_i18n.close_label='CLOSE'; jQuery(document).ready(function(){ jQuery('.catablog-image').catablogLightbox(); });
<!-- End CataBlog LightBox JavaScript -->

{}

which meant the Print My Blog Javascript wouldn’t know how to handle/parse it.

I was previously handling polluted JSON similar to this, but this was trickier because that initial “pollution” contained a {character, which could mean the start of JSON.

So I modified the code to recursively search for valid JSON substrings. I updated my blog post on how to do that, so you can look over there if you’re interested in the solution.

Most readers are probably just interested to know: even if other plugins are interfering with proper WP REST API JSON responses, Print My Blog should now continue to work fine.

So problem solved (which problem turned out to actually be from another plugin). But alas, the reviewer has yet to update their star rating. That’s a little upsetting, but life. I’m happy to have joined the “plugins where someone left a (seemingly) unfair review” club.

Also, while debugging the previously-mentioned issue, I realized the print page wasn’t rendering the WordPress footer. That’s where many Javascript scripts are rendered, so adding it may fix some plugin compatibility issues. One obvious change is that if your logged in, the logged-in navigation bar now appears.

So, another benefit from being attentive to users’ needs (even if it hasn’t gotten the 3-star review changes to a 5 yet!)

Thinking Out Loud

I got some feedback on my idea to sponsor development entirely via donations from a few people.

Mateo Duò commented

[Image removed]

The sponsorship/donation models could be a neat way not only to generating some steady revenue, but also a solid way to build relationships with other companies and brands. That’s where sponsorships get more interesting in my mind.

From that, I understand he suspects donations from users will probably be less rewarding financially than sponsorships from other companies and brands looking to get noticed and build a positive reputation.

If I were able to attend more WordCamps it would probably help greatly in building connections that could lead to sponsorships. But alas, with 3 kids under 6 at home, my priority and timers still quite focused at home. But I can still do my best from home.

Also, I think companies and brands will be more interested in sponsoring as they see Print My Blog becoming a bigger deal.

Mario Peshev and I started a short discussion on Twitter (btw, the conversation started because I had a question about his book, and somehow the conversation turned to this side hustle of mine.) He said

[Image removed]

Profitability in the WordPress ecosystem is one of the hardest endeavors I’ve ever encountered.

We all know about the “race to the bottom” but technically, it’s race to the freedom. The mentality for giving back is missing.…

For the most part, it’s about “commercial value” and “audience”.

The default WordPress user isn’t going to generate recurring profits from their website. Consider all applications of WordPress – link building satellite websites, blog spinoffs, students’ school projects, yada yada. A small chunk of them are actually designed to make a real profit (or at least have the potential to).

The way forward is focusing on paying audiences and a product business that can 1) scale, 2) has a large enough potential market cap, and 3) notably reports a positive ROI

My 2 cents at least. In your case, the general user who wants to print their blog is likely looking to shut it down or the like. Now, publishing firms may be a different target, which is where a SaaS licensed option may work better than sponsorships, but you get the point I guess.

Nevertheless, I’d love to see the experiment evolving for a few more months.

So most WordPress users aren’t actually making money using it, so likely won’t be willing to spend much on it either. Much less donate to it.

If I want to make an income, I need to focus on meeting the needs of companies and agencies, especially publishing firms. Using a more typical licensing model would be more likely to be profitable than seeking for sponsorships.

One trouble with that, for me, is that I don’t know what publishing agencies needs look like at all. So I’d like to continue to try this experiment of financing it via just sponsorships, because it has a lot of theoretical upsides. But I’m aware I might never find a way to make it sustainable.

Priorities

What’s up next?

Loading Dynamic Javascript From the WP REST API

An ongoing issue with the plugin is integration with plugins that require dynamically-added Javascript in order to be displayed properly. An example is Foo Gallery.

I have an experimental version that adds the currently enqueued scripts to the WP REST API JSON response, and then dumps them into the page, and then they get executed. The trouble is it loads the Javascript in a different order than normal web requests, which sometimes doesn’t work, depending on the code. Anyways, that’s my main priority with the code currently. Please let me know in the comments if you’d like to suggest something else!

Right now I’m just working on this plugin in my “spare time”. But I can work anytime from anywhere, and when I’m not working it’s actually probably best for me to spend some time with family. So it’s helpful if I could be compensated for my time working on this side project.

While the active installs have been growing steadily, donations have totally stopped. I don’t expect everyone to become a sponsor, but some percentage like 5% would really help this become sustainable.

I’ve been tempted to want to blame others that hasn’t gone too well. E.g., “Users just don’t ever want to give back!” But I’m realizing I need to take more ownership of it. Instead of blaming others, I need to focus on what I can change to improve it.

So that will also be a focus in the coming month.

Thoughts?

I’ve basically resolved to not work on anything unless a user specifically requests it, so if you see anything that can be improved, please speak up! And thanks to all those who have already spoken up in the support forums and on my blog posts.

Is Blogging in Conflict with Privacy? (Or, How to Effectively Use Password-Protected Posts)

https://cmljnelson.blog/2019/05/10/is-blogging-in-conflict-with-privacy/ May 10, 2019

4 minute read
I enjoy blogging but I’ve had mixed feelings about sharing details about others that they might not want to be so publicly accessible. In this post I’ll describe my thoughts on blogging vs privacy, and how I balance the two.

What Is The Purpose of a Blog Anyway?

I’ve written an entire post on this, but I have two somewhat incongruent objectives:

- Share my ideas, opinions and knowledge with the world

- Share my experiences and memories with family and friends

The first is served well by having a public blog, but the second not so much. Especially when most of my memories and experiences are involve others, and they might not always be comfortable with their stories being made permanently public.

Blogging vs Privacy

So, I’d like for some of my posts to be public, but others to only be accessible to friends and family, and maybe acquaintances. When I post something, I’d sometimes like it to only be as public as sharing it with someone at our local WordPress meetup, not as public as putting it on billboard along the highway.
Here’s a concrete example: I’d like to share stories about my family, including my sweet little girls, but I don’t want those stories to be easily findable in 15 years by their high school friends (or enemies). I.e., I’d like some of my posts to come up first on Google, but others to never come up at all.
So, how can you achieve this?

Why not just post to Facebook?

Facebook allows you to post to all sorts of levels of visibility. So that seems like a good match right?

- Not everyone is on Facebook

- Facebook might not be around, or the same (eg, still be free, allow me to publish what I want, or even work for me) in a few years

- It probably says on their user agreement that everything I put on Facebook is their intellectual property. I’d prefer to keep it, thank you.

Why Not Just Make My Blog Private?

WordPress.com and Blogger.com allow you to make your blog totally private, so only specific users will be allowed to read it, so that sounds like what I want. But there are drawbacks:

- None of your posts can be public. Eg, you couldn’t be reading this post right now unless I specifically sent you an invitation, so my blog couldn’t serve as my “public soap box” for my ideas, opinions, and occasional stories I actually want to be public

- I dislike signing up for yet another service, so don’t want all my friends to need to sign up for my site also (plus sites get hacked occasionally, check out https://haveibeenpwned.com)

Why Not Just Replace Everyone’s Names with Their Initials?

I’ve seen some blogs where they replace friends and family’s first names with just a letter. Actual friends and family know who they’re talking about, but not creepers on the Internet, and it will be hard for someone to search for stories on that individual in the future. But here’s the downsides I see:

- It’s a bit less readable (especially when it gets printed out)

- There may still be information in the posts that gives away individuals’ identities to strangers anyway (eg which school my child attends, who their teacher is, etc)

- you also can’t search it very well. So if I want to search my blog for all stories about my daughter, I can’t.

How I Balance Sharing and Privacy With Password Protected Posts

So, here’s my “medium security”, free, solution to balancing blogging and privacy.
I have a blog on WordPress.com, (although this approach works equally well for self-hosted WordPress blogs.)
The blog is public, so anyone can find it using a search engine.
For posts I want totally public, I just write and publish them as normal.
For posts that contain personal information, here is what I do:

1. Write the post as normal, using full names and as much information as I would share with a friend (or even trustyworthy acquaintance). So I use full names and add pictures (although I don’t set a featured image with anything personal in it, like faces, because some themes make featured images public; the post’s title will also be public)

2. Before I publish it, I add something like this at the very start “This post will be password protected. If you’d like to read it later, use the password ‘xxx'”.

3. I publish it. My blog’s subscribers all get an email and get to read the post.

4. I then change the post’s status to “protected”, add the password, and remove the line at the beginning saying what the password is. In the future, only people with the password can read it.

5. I share a link to the post on Facebook to my friends, and also tell them the password. Now they can read it too.

Also, I have a page explaining this “policy” on my blog. I tell visitors to subscribe to see future password protected posts, and to email me if they would like to read an old password protected post. (I may use the same password for posts, and could give a clue to it on that page; so mostly just friends would figure it out, but certainly not search engines).
And lastly, if I want to create a post strictly for my memory only, I create a private post. Easy.

Benefits

- My blog can have public, semi-private password-protected, and private posts

- Existing subscribers can easily read my protected posts from the emails they get; they also know the password so they can access it later on my blog or comment on it

- Facebook friends can read password protected posts too

- My password protected posts won’t show up in search engines, or be readable to total strangers

- I can also remove followers if I were to decide I didn’t want a particular person reading my password-protected posts

Drawbacks

- A friend or subscriber who gets a post’s password might share it with others. This is the online equivalent to them passing on the information. The difference is that the 3rd party can read the original content too, not just what my friend or subscriber related to them

- While it’s better than requiring others to create an account in my site, it’s a bit of a pain for them to enter a password. This can be mitigated by using the same password on all posts, because WordPress remembers you provided that password before, and so avoids requiring that you enter it again.

- It’s a bit of a manual process for me, I could make a mistake

If you’re more concerned over privacy than I am, you may prefer a private blog, or no blog at all. But for me, this maintains a comparable level of privacy to what I have in “real life,” while also sharing what I want with friends, acquaintances, and the general public.

Truce!

So that’s what I do to balance my desire to be heard and record through my blog with the desire to maintain some privacy.
What do you do to balance privacy and sharing? What do you think of my plan?

Me: Self Hosted!

https://cmljnelson.blog/2019/05/20/me-self-hosted/ May 20, 2019

1 minute read
I finally made the move from WordPress.com to becoming self-hosted.

I was able to bring all my old posts, pages, categories and tags, images and other media, and even subscribers. So if you were subscribed to my .com blog before, you’re now automatically subscribed to this new self-hosted one.

I have yet to pretty it up like before, and JetPack is giving me some grief… but my main to-do items actually relate to the old .com blog…

You see, obviously I’d like everyone to be automatically redirected from the old site to the new one. The only problem is WordPress.com wants $17/year for that. And I’m cheap, an don’t want to spend the money on something so trivial for them to do. So stay tuned to hear about any updates…

But in the mean time, don’t expect new posts on the old .com site, all my posts will come from cmljnelson.blog from now on.

How I Moved from WordPress.com Without Paying for the Redirect

https://cmljnelson.blog/2019/05/22/how-i-moved-from-wordpress-com-without-paying-for-the-redirect/ May 22, 2019

3 minute read
The Problem

I just moved this blog from WordPress.com and wanted to share about an unexpected hiccup and how I worked around it: WordPress.com wanted to charge me $17/year to forward visitors to my new self-hosted site.

While $17 a year isn’t going to break the bank, the principle of the matter is this: it costs them nearly nothing to redirect visitors to my new site (in fact, it’s probably much cheaper than hosting the old site). What’s really going on here is that WordPress.com is feeling jaded, and so she slapped me in the face with an unexpected fee. Well, I’ll show it…

It’s hard to work around, because WordPress.com is good about not allowing me to add any Javascript to my posts, which could take care of performing the redirect (like I did when I migrated from blogger.) And they certainly didn’t let me touch any HTTP headers. So what to do…

My Solution

Basically, I replaced the post content from all posts with a link pointing to the same post on my new blog. So basically it’s a manual redirect. I think humans will find it intuitive enough, although I’m not sure about search engines. Oh well, the best is yet to come, and I’m not paying $17!

So for I manually update all 100+ posts? No, the gist of what I did was this:

1. Exported all my posts from WordPress.com to a file

2. Replaced cmljnelson.wordpress.com with cmljnelson.blog in the file

3. Used Notepad++ to do a regex Search-and-replace to change the post content of all posts in the file (more details in a moment)

4. Trashed all my posts on WordPress.com (otherwise, in the next step, they won’t get updated)

5. Imported the posts back into the WordPress.com site

[Image removed]

Using NotePad++’s Search-and-Replace

Here’s the regex for selection:

<title>(.*?)<\/title>(.*?)<link>(.*?)<\/link>(.*?)<content:encoded><!\[CDATA\[(.*?)\]\]>

and here’s the replacement string:

<title>$1</title>$2<link>$3</link>$4<content:encoded><!CDATA[<p>I've moved from WordPress.com to a self-hosted site!</p><div class="wp-block-button aligncenter"><a class="wp-block-button__link has-background has-vivid-cyan-blue-background-color" href="$3">View the Post "$1" on my New Blog</a></div><div class="wp-block-image"><figure class="aligncenter"><a href="$3"><img src="https://cmljnelson.blog/wp-content/uploads/2019/05/img_8498.jpg" alt=""/></a></figure></div>]]>

So if you’re familiar with regex’s, you’ll see I’m grabbing the post’s title and URL, then stuffing them into the new post content. (Note: if you’re actually using this for your site, note that I needed to make sure I skipped the first occurence of the regex pattern, as it matched the site’s “title” tag, which isn’t what we want.)

Now every post on my old WordPress.com site looks like this:

[Image removed]

My old site from a mobile phone.

Oh, and a few other miscellaneous changes:

- I renamed the site to “CMLJ Nelson’s Old Blog”

- I replaced all the menu items with a single link to my new site

- I changed the homepage to be a similar simple page with a link to my new site

- I removed all the widgets (to simplify the page)

Why Not Pay the $17 Annual Fed?

I don’t want to keep paying it perpetually, and don’t want to pass my credit card info over to someone more (I haven’t spent a penny on this blog yet, although they have had advertisements on it, and I think my content has been beneficial to WordPress ecosystem.)

Should WordPress.com do the redirect for free? Maybe it’s necessary to make ends meet (I got a ton for free), but I’m still using JetPack for the time being, so I haven’t completely abandoned Automattic’s services. But I know replacing my entire old site with a simple redirect wouldn’t cost them a penny, and would cut down on a lot of expenses (they’re still hosting 3GB of my images), and was what I expected they would do when I decided to grow up and leave the WordPress.com home.

(Right now it feels like I moved out but my parents are charging me to forward my mail… it’s just a little rude and uncharacteristic of the people who raised me… [Image removed] )

Anyways, tell me I’m a fool in the comments.

PS: The featured image is another masterpiece by my daughter. It’s “fluffs” going on a boat ride.

WordCamp Vancouver 2019 Session Proposals

https://cmljnelson.blog/2019/07/27/wordcamp-vancouver-2019-session-proposals/ July 27, 2019

2 minute read
The following are some WordCamp presentation proposals I sent in for WordCamp Vancouver 2019. They thought the second one, “Zombie plugins,” would be good. But unfortunately, once it got accepted, Amanda and I decided the timing isn’t great for me to attend WordCamp this year. Our youngest is only 6 months, and we will have just moved into our new fixer-upper house.

Anyway, here’s what I had proposed:

5 Mistakes Non-Developers Make Choosing WordPress Plugins

WordPress plugins allow you to make cool and useful websites, without knowing a lick of code. But there are some pitfalls non-developers tend to make when choosing them. Is it more expensive to pay for a premium plugin, or hire a developer to write custom code? Should you choose a theme that replaces plugins? Where should you get plugins from (and what should you pay for?) Can the WordPress community help you choose a plugin? If you need customizations, how can you find the most well-qualified developers? These are all questions I will answer, in order to help you make the best use of WordPress plugins.

Note: this was based off this WordPress Meetup presentation.

Zombie Plugins: What to do When Plugins get Abandoned

Sometimes, good WordPress plugins, even popular ones, get abandoned by their developers. It can be scary, especially if your website (or business) depends on them! They’re a major security concern and time sink.

Let’s understand why some WordPress plugins meet this end; how you can help keep them alive; and what you can do when they’re totally dead. There’s not only hope, but opportunity.

Note: I have a half dozen draft posts on this topic, but nothing published yet. Let me know in the comments if you’d be interested in learning about this.

Time Traveling for WordPress Blogs

In a few decades, someone will want to read your blog. But your hosting plan will be expired, the software that runs it will be woefully out-of-date, and your backups will be corrupted. Most likely, your data will be lost. Future generations will refer to our time as the “Digital Dark Age”.

Let’s explore the software, mediums, and organizations that could help preserve your blog’s stories for the future.

Note: this was going to be on the same topic as my posts on the Digital Dark Age and Your Blog and Preserve your Story with Print My Blog WordPress Plugin.

And just for completeness, this was my speaker bio.

Speaker Bio

Michael Nelson is author of Print My blog, developer for Event Espresso, WordPress core contributor, Meetup Organizer, small “b” blogger (cmljnelson.blog), and family man. Canadian, lived in Mexico and USA, of French and Irish descent, and, according to his family tree, 1000th part Mi’Kmaq.

Print My Blog Transparency Report – July 2019

https://cmljnelson.blog/2019/08/01/print-my-blog-transparency-report-july-2019/ August 1, 2019

4 minute read
This is the 4th monthly transparency report for Print My Blog WordPress plugin. Mostly I’ve been responding to support requests and making corresponding small tweaks. There were no major releases this month, but 5 minor ones.

What Happened in July 2019

[Image removed]

Downloads per day are generally up. These have all been minor releases so folks might feel less worried about upgrading to them.

[Image removed]

Growth continues to be basically linear. That’s good.

- Hours:

- 22.25 (+3.75) support

- 28.25 (+2.25) copy writing

- 62 (+8.5) development

- 6.5 (+0) management

- Expenses: $4108.66 (+519.75)

- Donations: $40 (+0)

- Downloads: 7618 (+1847)

- Active Installs: ~600 (+100)

- Languages: 3 (unchanged)

- Five Star Reviews: 16 (+1)

- Releases: 32 (+5)

Overview of What’s New

- User Interface Touchups

- Fixed Small Inline Images

- Using More Site Styles

- ePub Printing Difficulties

The Details

User Interface Touchups

While I have a really long list of features I’d like to add (including making my “ask” for donations more prominent) there were also a number of good support issues brought up that I tried to address. In addition to trying to fix the user’s immediate issue, I tried to improve the plugin in order to avoid the problem for future users.

In 1.9.3 I added a link to explain how to print to PDF (as user todindiana wondered how to do it, and of a truth it wasn’t really explained anywhere) and added link to cancel printout (as suggested by Martha Lindeman, who had an error but wasn’t sure how to abort preparing the print page).

In 1.9.5 I added a suggestion to the print page to use the browser’s print preview (in response to this support issue where I thought the user thought the print page, which holds all the printout’s content, was a true print preview…)

Hopefully these changes will lead to a smoother experience for future users.

Fixed Small Inline Images

If you are printing a web page with large images, often browsers will “chop the image in half” across page breaks in order to save paper. Print My Blog avoids that by wrapping images in div tags that instruct the browsers to avoid that. But one side-effect of this is that the images must take up the entire width of the page.

That seemed ok to me, and I had made a few exceptions for image galleries and emojis, etc. But user Philip Rueker also noted that even small and medium-sized images were taking up the entire page width, and browsers usually do a fine job of not chopping them in half. So I made an exception so small and medium images can be shown inline in printouts fine.

Use More Site Styles

If your theme used custom CSS that relied on the “site” CSS class, it wasn’t applying to Print My Blog printouts. That’s because I just wasn’t adding it onto the top-level div.

In 1.9.6 I added it. Hopefully printouts will apply more of your site’s style.

Along with that, it’s possible that now you’ll have more background colors from your regular site appearing in printouts, so you may want to use your browser’s built-in ability to remove background colors. So I also added a FAQ explaining how to do that with Google Chrome, Firefox, and the Firefox Extension Print to PDF.

ePub Printing Difficulties

User alemarcanob was wondering how to create an ePub file from their blog for reading from their e-reader. I had incorrectly thought this would be an easy task with Print My Blog.

There is a free browser extension called dotepub that is meant to convert web pages to ePub and mobi files. Unfortunately, it doesn’t work very well with Print My Blog: it just grabs the first post from the printout, and its missing most headings.

I contacted its author to try to resolve the problem. The software analyzes your website and makes a best guess at what content is relevant for a the e-book, and which should be removed (eg site headings, sidebars, footers, etc). Sometimes it gets it wrong, so he suggested I start with a very simple page and add more content to it gradually, trying dotepub each time, to identify what was causing the problem.

I hope to get around to doing that soon, but admittedly it is getting harder to investigate these trickier issues for free. Like dotepub’s author, this is ran just by donations, and sometimes you want premium support to get issues resolved in a more timely manner.

Update: I have an experimental version of the plugin that works well with dotepub. I’d currently like someone else to test it.

Thinking Out Loud

Possible Paid Add-ons

The fund-by-donations model doesn’t seem to be producing great results, as most people could have predicted. There’s still more I could do to improve it, I think, but my interest in doing so in waning. I’m leaning towards offering the main plugin for free, which will continue to serve the mission of preserving our blogs, and offering paid add-ons for those with more resource-intensive needs. Some ideas so far:

- Advanced Custom Fields Integration

- Custom Post Type Integration

- ePub Printing (even if I do resolve the issues with dotepub, their branding is still being added, and it doesn’t separate posts into chapters or anything)

- WPML support

The Happiest Users Giving Poor Reviews

It’s funny that I’ve had a number of rather happy users giving bad reviews. Most recently, Print My Blog received a 2 star review because its missing a feature to show posts for multiple languages. I was quite happy to have the plugin available in another language last month, but that progress might also resulted in an overall lower star rating for the plugin (because those new users want more features)!

The other users who gave a 3 or 4 star review were rather happy, but seemed to be giving a poor-ish review in order to get the features they’d like added.

I try to take these suggestions to heart, despite not being excited about the poor review. Still (gets up on soap box) if folks want a plugin to improve, it’s actually more helpful to leave a good review, support the project, and leave a helpful support issue detailing how you’d like it to improve. That’s my opinion anyway. (Gets down from soap box.)

Anyways, hopefully I’ll get around to adding some more features, and building a more sustainable model future support and development in the coming months. Please leave a comment if you have any suggestions.

Quickly Turn your Entire WordPress Blog into an eBook with Print My Blog and dotEPUB

https://cmljnelson.blog/2019/08/12/quickly-turn-your-entire-wordpress-blog-into-an-ebook-with-print-my-blog-and-dotepub/ August 12, 2019

5 minute read
In this tutorial, I’ll show you how to use Print My Blog plugin and dotEPUB browser extension to convert an entire WordPress blog or website into an eBook.

Why would I want an eBook of My Blog?

Blogs are great, but eBooks

- can be read offline

- keep track of your progress

- allow you to highlight passages and take notes.

Generally, a reading a blog’s content online is great for reading a post here-and-there, but an eBook is nicer if you intend to read the entire work.

For example, I recently discovered the Freemius blog, which has a lot of thoughtful articles. I basically wanted to read all of them, but I usually only have 5-15 minute stretches of time to read. I’d invariably forget where I left off. I also recently switched to a much cheaper cell phone data plan, so I’m wanting to avoid re-downloading it every time.

I got my hands on a PDF copy of their blog, but I’d really prefer an eBook. PDFs are good for reading from a wide screen, like a computer, but require endless “pinch-and-zoom”ing from my phone. That was actually what finally motivated me to finally add better eBook support to my plugin Print My Blog…

How To Make An eBook using Print My Blog and dotEPUB

Here’s a video showing exactly that. But if you prefer to read it, read on.

1. Get dotEPUB Browser Extension

dotEPUB is a browser extension for Google Chrome, Mozilla Firefox, and Apple Safari (actually, there is an applet I think you can use with any browser.) It can take any web page and turn it into an eBook: either an ePub (for Kobo, Google Reader, and others) or MOBI (for Amazon Kindle) file. Oh and it’s totally free (the author just takes donations.)

So first, go to dotepub.com, and add the extension to your browser.

[Image removed]

Links to install the various dotepub extensions are located halfway down the homepage of dotepub.com.

2. Install and Activate Print My Blog on your WordPress Website

Print My Blog is a WordPress plugin that can stuff all your posts into a single web page in order to easily print it all at once. But instead of printing to paper, we want to “print” to an Ebook.

[Image removed]

Install and activate it directly from your WordPress dashboard (going to plugins, “add new”, then search for “print my blog”, and click “install”, then “activate”).

[Image removed]

3. Use Print My Blog to Prepare your blog’s content for dotEPUB

Upon activation, you are taken to the print setup page. Make sure you specify format to be “eBook (ePub or MOBI)”, then pressing “Prepare Print Page”.

[Image removed]

(There are many other options, like filtering posts by post type, category, and date published. Those are optional.)

Wait for Print My Blog to say the print-page is ready.

[Image removed]

4. Configure dotEPUB

dotEPUB has a few options too, which can be changed like any other browser extension. In Firefox, go to menu, “Add-ons”, select dotEPUB, and lastly options.

[Image removed]

If you want to read your eBook from a Kindle (device or app) specify you want a MOBI file. Otherwise, if you want to read it with why other app or device, choose ePub.

The choice of “immersive mode” or not is a personal one. If it’s enabled, images and links will be removed. Otherwise, they will be inserted into the eBook (although if there are too many images, which would make the eBook huge, they will automatically be replaced by links).

5. Use dotEPUB to create your eBook

This part is silly simple. Click the dotEpub icon and it will create the eBook according to your requested settings.

[Image removed]

Note: dotEPUB will probably give you a few warnings, if you have a lot of images or if the eBook is really long. From my testing, those aren’t a problem.

Within a few seconds, the eBook will be downloaded to your computer or device.

What to Do with your eBook

Get it on your phone and read it

If you’re like me, you probably did all the above steps from your computer, but want to do the actual reading from your phone. In that case, you can compose an email and add the eBook as an attachment, and send it to your own email address. Then open that email, and download it to your phone.

If it’s a MOBI eBook, you’ll need to open it with the Kindle app. For ePubs, Kobo is a good choice (although there are dozens of alternatives).

Share it with Site visitors

You can also upload it to your WordPress site using the media uploader, and provide a link to it from a page, and let visitors download it for free.

Alternatively, I bet you could use a plugin like Easy Digital Downloads to sell it.

Store it as Low-Tech Backup

You should already have automatic backups of your site, which are great if your site somehow goes down or gets hacked, but they will be hard to use in a few years. That’s because they rely on the current versions of software, which gets updated so fast, in a couple years it might be quite difficult to get just the right combination of PHP, MySQL, nginx, etc etc. Your site could fall victim to the “digital dark age.” So it will be really nice having an eBook (or PDF, or better yet paper) which can be used with fewer technological dependencies.

Alternatives

Are you not on WordPress? You can go to bloxp.com to create an eBook any blog that has an RSS feed.

If your WordPress site is hosted by wordpress.com, you can use Dead Easy Family History, which has a hosted version of Print My Blog.

Update: another good, free alternative I discovered (after writing this post) is the MPL Publisher plugin. It also allows you to create an eBook from your entire blog really quickly (one that’s basically ready for self-publishing, whereas Print My Blog’s really isn’t quite there yet.) The only downsides are that the images in the generated ePub require an internet connection to see, and it hasn’t been maintained in a few years.

More alternatives were mentioned in the WPTavern article from 5 years earlier on a similar topic, but already many of them no longer exist. Still, it may be a good read.

That’s It!

If your site has lots of posts, I think it’s courteous to provide visitors with an eBook option in order to facilitate reading all of it. Alternatively, you could add a category called “Favorites” to all your favorite posts, and use Print My Blog to only put those posts in the eBook.

Either way, I’d love to hear how you use Print My Blog, what questions you have, and what you’d like to be able to do with it.

[Image removed] [Image removed] [Image removed]

If you use dotepub often, consider making a donation. Your contribution allows us to continue its development.

Disclaimer

This information was automatically retrieved on 2019-08-15T17:53:30+00:00 from:

https://cmljnelson.blog/?post-type=post&taxonomies%5Bcategories%5D%5B%5D=18&dates%5Bafter%5D=&dates%5Bbefore%5D=&show_title=1&show_url=1&show_date=1&show_featured_image=1&show_content=1&printout-meta=on&post-page-break=on&columns=1&font-size=normal&image-size=full&links=include&rendering-wait=200&print-my-blog=1&format=ebook

and automatically parsed, clean up and interpreted by dotEPUB.com. It is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. This e-book is not an authoritative source: please, visit the original webpage.

(v. 0.8.17 / f1.2 IL)