My apologies for the selfish and personal nature of this post. I hope you will forgive me given the circumstances. As most of you know, I was diagnosed with stage 4 colon cancer in 2013.
One of the things my wife and I are trying to do is put together some information about my career that will hopefully give my 6 year-old daughter a better sense of who I was as an adult. She knows me as “dad”, but when she gets older she’ll be curious about who I was to my peers and colleagues.
I’ve spent more than a decade in the WordPress community and I’d like to request that you to share a few thoughts or remembrances about me that we can compile and share with her when the time is right.
If we have crossed paths or if I have managed to do something that you found helpful, I’d love it if you would take a few minutes to write it down and send it to me or my wife: heatherkingcom@gmail.com. If you’re willing to have the story shared publicly, please indicate that accordingly. By default, we will keep everything confidential.
This post is part of the thread: Cancer – an ongoing story on this site. View the thread timeline for more context on this post.
]]>
I was originally hoping to have the modified theme hosted on WordPress.org but after weeks of waiting for review, they responded that features of the theme like choosing colors and post formats should be done in separate plugins instead. This makes no sense to me as these are core features of the theme, but happily there are great places like GitHub that will host the project for us.
The Personal theme is quite assuredly mobile-friendly, which makes it a great fit for the importance Google’s is placing on mobile-friendly sites lately.
You can download from the releases page on GitHub or, for you technically minded, grab the reop with git. Just make sure to also grab the submodules.
git clone git@github.com:alexkingorg/wp-personal.git
cd wp-personal
git submodule update --init --recursive
This post is part of the project: Personal Theme. View the project timeline for more context on this post.
]]>FWIW I’ve posted to my own site first then passed stuff along to Twitter and Facebook since we released the Social plugin for WordPress back in 2011. Each of my posts has a link to its counterpart on Twitter and Facebook, and reactions on those networks are brought back in as comments on this site. Special handling is done to thread comments based on Twitter’s reply_to property, as well as a retweets, etc. More details about how this works can be found in the blog post I wrote back in January on the Crowd Favorite blog.
When I’m mobile, I’ve found that using the WordPress admin web interface is better for my needs than the iOS app. Mainly because of additional post meta that I utilize on this site.
]]>$response = wp_remote_get($url, array(
'timeout' => 20,
'User-Agent' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0'
));
Thankfully, Otto spotted my problem. The `user-agent` key needs to be lowercase so that it is picked up properly by the WordPress core code. This works:
$response = wp_remote_get($url, array(
'timeout' => 20,
'user-agent' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0'
));
And there you have it. It’s always nice to have an extra set of eyes on some code.
]]>5 minutes later I had BackupBuddy installed, with a nightly job configured to do a full export of my database and store the last 10 days of backups in my Dropbox account.
Sure, I could have written the code to do this myself. It’s always tempting to do-it-yourself when you know you can do something. The key is to ask yourself if you should do something. It would have taken much more than 5 minutes to get even a simple backup script written and configured; and I definitely wouldn’t have had the storage and and automation options that BackupBuddy provides out of the box.
If you need hassle-free backups for your self-hosted WordPress site1, give BackupBuddy a try.
When the distraction-free writing mode was overhauled in WordPress 4.1 my little Preview Button plugin was rendered non-functional. Never fear, it’s now been updated and works a treat.
This post is part of the project: Fullscreen Preview Button. View the project timeline for more context on this post.
]]>1) You don’t have to deal with updates to the platform. Updates and new features are nice, unless they break all the custom code you’ve developed over time.
WordPress has well abstracted APIs that make it easy for your custom code to live alongside the WP core code. I can’t remember the last time I needed to make a change to code I’d written for this site because of a WP core update.
2) You can’t control when bugs are fixed or new features released. If there’s something missing, the only thing you can do is file a request and wait.
Fiddlesticks. You can submit a patch, you can hack your local copy, and you can write plugins to add any features you feel are missing.
3) There’s always a learning curve. Every platform is different, specially when you want to fine tune your layout and deviate from the provided templates.
This one strikes me as a bit silly. There is a learning curve when building your own system too – especially if you haven’t written your layout/templating system yet.
4) Sometimes there’re things you can’t do. Period. (I wanted to use a specific format to display the date of my posts but Blogger doesn’t support it. I had to settle with something else.)
Using a hosted service and using an off-the-shelf blog engine are not the same thing. Self-hosting WordPress removes all of the hosted service restrictions.
5) You have to deal with features you don’t need. Comments? Related posts? Search? Templating engine? Image carousel? I don’t need these, but I’d have to pay the price anyway.
Just as you can customize WordPress to add features, you can also customize it to hide features. Don’t use comments? An included setting and couple of lines of CSS will make it so you never know they were there. And WordPress doesn’t include bloated features out of the box; it wisely leaves that to plugins so that you add what you want instead of removing things you don’t.
6) You can always export your content (sometimes you can’t), but even when the option is right there, the exported format is so messed up that you can’t use it again without a huge clean up. (One time I got my posts exported in a text file with no formatting.)
Again – this is only a problem with hosted solutions. With a self-hosted WordPress site you have full access to your MySQL database, as well as the built-in export features of WordPress.
7) What’s true today might change tomorrow. What you like about the platform might go away some day. They won’t ask for your opinion.
WordPress is Open Source. Anyone can create a fork based on their own needs and preferences.
8) It will never be as fast as you want it to be. If it’s hosted, your traffic will be shared. If you host it yourself, you might never be able to fine tune it to perfection.
WordPress powers around 20% of the internet – you don’t grow that big if you can’t handle scale. Dedicated WordPress hosts will solve these problems for you, and installing a few simple plugins (caching, CSS and JS concatenation and optimization, etc.) will do a ton to optimize a site on an server that isn’t tuned for WordPress.
9) I will never be sure what my content is being used for. I know it’s public anyway, but it’s also in somebody else’s database I don’t control.
Another assumption of a hosted platform. NA for a self-hosted WordPress site.
10) You’ll never get to experience the satisfaction of engaging in a conversation about how you developed your own platform from scratch.
As someone who has hacked on WordPress and related code for the last 12 years, I find this statement absurd. There are plenty of “from scratch” opportunities within the WordPress community, even now. And if what you want is engagement then joining a bountiful and vibrant community of developers is a much bigger opportunity than the potential for a conversation with another NIH hacker.
I’m not saying that there is anything wrong with building your own X. Every time you do that it’s a great learning experience. I’m saying I don’t think it is necessary to get pride of ownership.
There might be something out there that offsets all my concerns, I’m not sure (but I don’t believe so.) My blog is my hobby, and I think I’d never give control again. Every single bit you see here was a labor of love, and I’m not ready to stop thinking about it that way.
I think a self-hosted WordPress site is really close. And I feel exactly the same about my site – it’s mine and I am in control of it. Even though I’ve released much of the code for this site as Open Source, no one else has a site that’s exactly like mine. I’ve made the decisions about how to present my content, how to distribute it to Twitter and Facebook, how to integrate with the responses on those platforms, and how I represent myself online. And I do so while building on a robust base platform that allows me to concentrate on building just the features that are unique to my site.
]]>I think it’s worth considering who wins in this “race to the bottom”. In general, more stuff for free benefits consumers, which in turn benefits the platform.
“But wait!” the developers cry. “When the platform doesn’t support building more sophisticated apps, the consumers ultimately lose!” I know this argument, I’ve made it myself regarding the WordPress ecosystem. I was wrong.
Consumers have been well trained that they can expect incredible value for free. Sure, they may trade off their privacy and be subjected to ads, but they aren’t asked to fork over their cash directly.
VC-backed companies often contribute to the problem as well. As they clamor for users to their platforms, they give everything away – it’s so easy to flip the switch in the future and start the money pouring in. Or if that doesn’t work, they fold up shop and call it a day. Oops!
More complex apps will get made. They just won’t be built using the model that indie developers are used to.
There will be apps supported by alternative revenue streams. Some might have ads or sponsorships, some might mine and sell the data they produce, some (like Evernote and Dropbox) will be a gateway to a commercial service. People will figure out ways to get money out of a large enough user base, and apps will get built.
I’ve seen this happen in the WordPress ecosystem already. It’s a different beast because it’s an Open Source community, but it’s still an interesting parallel.
Basically this happened:
It’s not the
pure
and direct approach of charging directly for the software, but it’s still developers writing code and making money.
The same thing is happening for iOS. There is money to be made. The platform and consumers are winning.
“Adapt or die” is our mantra for those business who are threatened by technology. We have little sympathy for newspapers, the music industry, etc. Perhaps it’s time to include software companies in that list.
]]>I’ve talked a bit about when to use custom taxonomies and when to use custom fields/post meta (and how they can be used virtually interchangeably in some situations). If you want to use taxonomies, you’ll probably also want to:
This Gist is a good start:
| <?php | |
| // check for a term and insert it if it doesn't exist | |
| if (!get_term_by('slug', $term_slug, $taxonomy)) { | |
| wp_insert_term(__($term_name, 'localization-key'), $taxonomy, array( | |
| 'slug' => $term_slug | |
| )); | |
| } |
| // remove all functionality from hierarchical taxonomy UI box (other than term selection) | |
| // *and* convert the checkboxes to radio buttons to enforce single selection (this is untested) | |
| $('#taxonomy-' + yourTaxonomyName) | |
| .find('.category-tabs, div:not(".tabs-panel")').remove().end() | |
| .find('.tabs-panel').removeClass('tabs-panel').end() | |
| .find('input[type="checkbox"]').attr('type', 'radio'); |
| // remove all functionality from hierarchical taxonomy UI box (other than term selection) | |
| $('#taxonomy-' + yourTaxonomyName) | |
| .find('.category-tabs, div:not(".tabs-panel")').remove().end() | |
| .find('.tabs-panel').removeClass('tabs-panel'); |
You’ll probably also want to specify:
'public' => false,
'show_ui' => true,
when defining your custom taxonomy. This makes the UI box for the taxonomy appear in the post/page editing interface as expected, but hides the admin forms for editing the taxonomy terms from the admin menu.
]]>This post is part of the thread: Crowd Favorite – an ongoing story on this site. View the thread timeline for more context on this post.
]]>More than a little overdue, but better late than never – here are some photos from WordCamp Miami 2014. The full set is up on Flickr.
]]>Here’s Crowd Favorite‘s own Brandon Dove at the WordCamp Orange County golf tournament yesterday.
]]>While our first preference is to continue expanding our offices in Denver, Los Angeles (and Orange County), Las Vegas and Bucharest, we’re also considering remote candidates. The exception is for the junior developer position, we’re only considering candidates at our offices for that position so that we can more easily provide support and mentorship.1 We have a great developer-centric culture that embraces learning, sharing and best practices – come join us!
We’ve also updated our RAMP and Carrington Build WordPress products this week. RAMP handles selectively pushing content from your staging to your production environment while Carrington Build provides drag-and-drop editorial control for your high value pages.
If you’re thinking all this activity explains the lack of recent blog posts here, I won’t argue with that conclusion. 
This post is part of the thread: Crowd Favorite – an ongoing story on this site. View the thread timeline for more context on this post.
]]>