9seeds

Building Custom WordPress Solutions | Plugin Development

 

Jon Brown

9seeds Improves WordPress as WordCamp Los Angeles Sponsors

Supporting WordPress Locally as WordCamp Los Angeles Sponsors

Posted on

We love watching the WordPress community grow as well as help facilitate that this year as WordCamp Los Angeles sponsors. Attending the camp this year, we were pleased to see record numbers of attendees in workshops, sessions and conversation. The WordPress community has developed quickly in the last decade. We are grateful to have watched and contributed to that growth.

Although our donation, as WordCamp Los Angeles Sponsors, builds community in California, it also benefits WordPress users globally. Were you aware that each WordCamp forwards excess, unused sponsorship funds to the next camp? That means that our sponsorship changes lives in Los Angeles and also benefits newer camps, such as WordCamp Ahmedabad in India. How amazing is that?!

9seeds is dedicated to supporting open source software and are grateful that WordPress makes it easy to do.

It is gratifying to watch a community grow. Through years of WordPress involvement we’ve witnessed many individuals start new, build knowledge, contribute and emerge as leaders in their local WordCamps. We’ve seen it happen all over the world.

This happens because WordCamps deliver to the needs of every skill level. This year WordCamp Los Angeles offered two half-day workshops, a pre-camp Beginner Day and an Advanced Development Track. An on-site networking after party concluding the first full day of the camp, which gave attendees a chance to further discuss topics on all levels and connect informally.

We Enjoy Being WordCamp Los Angeles Sponsors

2017 provided many opportunities for involvement in the open source community. In June, I personally helped organize WordCamp Orange County. Throughout the year I’ve attended and spoken at many WordCamps, as did many of our 9seeds team members. We actively participate in the communities where we live because we know that our involvement makes a difference.

We’ve learned from one another and seen how our contributions and the efforts of others have improved WordPress. We value each community member and every experience and hope you do, too.

 

 

 

WordPress Triple Threat: Custom Development, Plugins and now Themes too!

Posted on

Since 9seeds first sprouted, building and selling WordPress products has been part of our DNA. We launched our first plugin in 2009 shortly after forming our company. Since then there have a been many plugins we’ve built for ourselves or clients, sold as products and supported, and we have even sold plugin code bases to other maintainers when we no longer were the best fit for them.

Over the years, however, most of our time has been spent building custom WordPress sites for clients. Principally building bespoke themes (design) as well as custom functionality (plugins). We’ve helped hundreds of clients take an idea they had for a site that did something unique and turn it into a living, breathing website customized to just their needs.

We’ve learned a lot about what works, what doesn’t, and how to avoid what might not be a problem today or tomorrow, but might show up as a problem next year and the year after. We still actively work for an maintain many of the sites we built in the first year. Granted, most of those folks have opted for full rebuilds since then.

One thing we’ve never done in all our years is to sell WordPress themes as a product, until now.

Building WordPress Products on the Side

As much as we’ve wanted to pursue building and selling WordPress themes, the immediacy of building custom websites for clients tended to take precedence over the long game of building and selling products.

Speaking of long games, 9seeds’ 8th anniversary is right around the corner. That may not sound like a long time but it’s a lot longer than most agencies focused on WordPress have been in business.

Since the beginning, the majority of sites we’ve built from scratch have been built on the Genesis Framework from StudioPress. That is not to say we’re exclusively a Genesis shop. We havee built sites on everything from Thesis to Headway, to Underscores, to Roots, to just rolling our own themes. We’ve always approached site development by choosing the foundation that is best for each individual client, but most of the time that is Genesis.

We’ve also built sites a huge range of sites from classic WordPress blogs to high traffic publishing sites like The Good Men Project. We’ve built membership sites like LendingMemo and 40DayJoyChallenge. We’ve built e-commerce sites like PowerPhone and Cardsmiths Breaks. We’ve even built private intranets and a bunch of sites we’re not allowed to talk about ;).

While a healthy portion of our clients opt to have custom themes designed from scratch, a good portion are also well served by leveraging existing commercially available themes. When clients do thier own them shopping we always guide them to one of two places – StudioPress’ own theme store or Web Savvy Marketing’s theme store.

The reason is simply that we’ve never had a problem taking themes from those two sources and using them out of the box, or heavily customizing them to suit. We have never had a problem with either which is more than I can say for the majority of themes we see from other marketplaces.

A match made in WordPress Heaven

While I’ve know Rebecca Gill from Web Savvy Marketing professionally and by her stellar reputation for many years. I didn’t get to know her well personally though until just the last year. We’d certainly cross paths WordCamps and across the interwebs but she tended to frequent the east coast camps while I frequented the west coast camps.

Internally 9seeds had often talked about building and selling themes on the Genesis framework specifically and about a year ago I sought Rebecca’s sage counsel on whether she thought 9seeds pursuing building Genesis themes was still a worthwhile business venture. WordPress is a fairly unique business culture filled with an atmosphere of friendly competition where asking a question like “What do you think of me going into the Genesis child theme business head to head with you?” just isn’t as bizarre as it might be in other contexts. Regardless, when I asked her this questions it had never occurred to me she’d even have considered letting go of the amazing theme store she’d built up over all these years.

It took a bit more time of getting to know each other personally before I came to hold the same feelings that others had shared about her. I felt deeply that this was a person I not only wanted to be friends with but wanted to be in business with.

It became apparent to both of us that this was a perfect fit.

9seeds would take over the store starting with support and new theme development that had slowed to a trickle. Rebecca would counsel me on getting our SEO and marketing skills up to the level excellence she’s achieved with WSM.

It’s a win for 9seeds by giving us a springboard into a market we’ve long had our eye on accompanied by the best trail guide in the business showing us the path.

It’s a win for WSM by freeing Rebecca and her team up to align with where her focus now is on larger custom site builds and SEO consulting.

Exciting Times Ahead

For me personally, this is my most exciting business step forward yet. We already have a theme in development that will be releasing once the store merge is complete.

We’re still working out the technical and design details of moving the support forums and theme store over from the WSM domain to 9seeds without interruptions or downtime. That’s a pretty daunting task given how long both stores have been around and that one is built on WooCommerce while the other is on Easy Digital downloads.

I know all of WSM’s loyal fans are going to be thrilled with what we’ve got in store. You can guess with 9seeds’ strong background in web publishing, memberships sites and more a bit what we have planned for the next year, but we’d love to hear from you all what you’d like to see in the comments.

How to change WordPress permalink structure on WP Engine

Posted on

One of the most user friendly and powerful SEO features of WordPress has always been it’s pretty permalinks feature. Many content management systems (CMS) still to this day have urls that look like http://domain.com/something_incomprehensible/123123c1. Ugly!

WordPress has supported pretty permalinks (human readable and ending a url with a slug resembling the post name) since version 1.0. There was one catch to those however. You needed to include a date in the format before the post slug (that’s /%year%/%monthnum%/%postname%/ for those familiar with WPs permalink formats). This resulted in URLs like this post’s URL: https://9seeds.com/2016/12/19/change-permalink-structure-wp-engine. Pretty!

That format has always still been better for SEO than what other CMSs do with crazy random numbers that mean nothing to human or search crawlers. It’d be a little better without the dates in the way however. You could use just the post slug (that’s just /%postname%/ ) on small brochure websites with just a few dozen pages, but on sites with large numbers of posts things would slow down without dates to break things up.

As of WordPress 3.3 there is no longer any performance hit to using just /%postname%/.  So your URLs can just look like this:  https://9seeds.com/change-permalink-structure-wp-engine/.  Prettier!

But there’s still a catch. You can’t just go into the WordPress Permalinks settings page and change formats or incoming links to your site using the old format may 404 🙁

There’s long been a fix for this and our friend Yoast even built a tool to make generating the needed .htaccess rule here since no one likes writing regex or coming up with htaccess rules.  That’s all well and good if you’re on a simple Apache server and want to edit an .htaccess file, but what if you’re on WP Engine? WP Engine uses a higher performance setup with an Nginx proxy in front of Apache. That means you can put those redirect rules into Nginx and they’ll be even quicker than having put them in .htaccess!  Only you can’t directly modify your nginx.conf files on WP Engine, instead WP Engine gives you a super easy to user redirect tab in their panel.

 

Here’s how you change your permalink structure and setup the needed redirect on WP Engine.

Step 1:

Go to Yoast’s handy tool here and generate the needed rewrite rule. It’ll look something like this:

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(?!page/)(.+)$ https://your-domain.com/$4

If you’re not on WP Engine you can drop that into your .htaccess file before the WordPress section. In fact it’ll work on WP Engine, just it’s better to use the panel than to modify that file directly via FTP.

Step 2:

1. Go to the WP Engine Dashboard and click Redirects rules in the left sidebar

2. Click the Redirect Rules button at the top right

3. Set a memorable name for the Redirect.

4. Take the orange section above, the scary looking Regular Expression that Yoast generated for you (mine is for year/month/date, your maybe be shorter if your existing permalink structure is shorter), paste that into “Source*” from the ^ to the $.

5. Take the blue section above, the less scary url looking Regular Expression from the http to the $4 (my existing permalink has three date modifiers, hence it keeps the 4th chunk, your’s may be different if you’re using a shorter permalink structure).

6. Click the Save button

Step 3:

1. Go to your WordPress dashboard and click on Permalinks under Settings in the left sidebar

2. Change your permalink setting to %postname%

3. Click the Save Changes button

Step 4:

Test!

 

Success? Awesome let us know in the comments below!

WordPress Performance

WordPress Post Editor Performance

Posted on

WordPress Performance sometimes seems like an endless quest, but there are sometimes little things that come along and yield great rewards.

Front end and back end WordPress Performance auditing and optimizing is a topic I’ve been meaning to write more depth about since speaking on the topic at a few WordPress meetups, but I wanted to quickly share a performance tip on something I came across today while preparing a bug report for Yoast’s WordPress SEO plugin.

Spotting Performance Issues in WordPress

One of the ways we spot performance issues is to run Query Monitor on most of the sites we work on. Query Monitor is a great tool for a quick view into what’s going on on the backend on every page view and I’ll go into more in a future post.

TL:DR; Skip to #3 at the end.

I am no Chris Lema, which is a abstract way of saying, “I personally don’t spend much time in WordPress post editor”. However, today I was in there investigating a little visual glitch with the WordPress SEO snippet preview metabox when I also noticed that the post editor was loading very slowly. Thanks to Query Monitor I could instantly see the cause was a slow MySQL Query and it was coming from a function called meta_form().

Now, this was on a client’s site with over 100,000 posts and with a site that size performance issues show up rather quickly. This however, does affects smaller sites as well though not to the extent it does large publisher websites like this one. Also just to be clear it is really impacted by the number of rows in the postmeta table, not the number of posts directly, but I figured saying 100,000 post made more sense that 1.8 million rows. On the big site like this one though it was causing a 15 second query. While loading the post editor is infrequent, even on a site like this one with over 100 authors, that 15s is taking up a valuable MySQL thread and certainly frustrating authors.

On my much smaller personal blog it was still delaying page load several seconds and here on 9seeds.com (two sites with no where near as big of a database as our typical client’s site) it was causing a 7s slowdown on the post editor loading.

WordPress Performance
Slow meta_form() database query

Geeky WordPress Developer Details of the slowdown

WordPress runs a function called meta_form() which displays the custom fields meta box. It runs a somewhat intensive query on the wp_postmeta to generate that box (a box most people don’t even need anymore, but that’s a whole separate issue).

That query looks like this:

SELECT DISTINCT meta_key
FROM wp_postmeta 
WHERE meta_key NOT BETWEEN '_'
AND '_z'  HAVING meta_key
NOT LIKE '\\_%' 
ORDER BY meta_key 
LIMIT 30

That’s actually the improved version of the query! When these changes were made to improve the query back in WordPress version 4.3 it seems that only half the needed changes to the database were made for existing sites. The table index was updated to 191 characters, but the field itself was not updated. That mismatch makes that query super slow on large wp_postmeta tables.

There is a new bug report for this performance issue already. While it seems like a trivial thing to fix any time WordPress core needs to modify the existing database on millions of WordPress it’s a pretty big deal and can take a while to get incorporated.

The good news is there are a couple fixes you can implement yourself.

1. (not recommended) My first fix was to truncate the meta_key column to 191 characters with:

ALTER TABLE wp_postmeta MODIFY meta_key varchar(191);

That worked, but it’s a bit dangerous since you could have a very long meta_key and it could get truncated, so don’t do that, there are better ways.

2. (recommended) Much easier, in WordPress 4.4 there was a new filter introduced that short-circuits that query ‘postmeta_form_keys‘ which you can provide a pre-defined array of keys to if you need.

add_filter('postmeta_form_keys', array('my_key1, my_key2');

3. (most recommended) Just ditch loading the ancient custom fields box entirely with:

/**
 * Remove Ancient Custom Fields metabox from post editor
 * because it uses a very slow query meta_key sort query 
 * so on sites with large postmeta tables it is super slow
 * and is rarely useful anymore on any site
 */ 
function s9_remove_post_custom_fields_metabox() {
     foreach ( get_post_types( '', 'names' ) as $post_type ) {
         remove_meta_box( 'postcustom' , $post_type , 'normal' );    
     } 
} 
add_action( 'admin_menu' , 's9_remove_post_custom_fields_metabox' );

Added to your theme or a core functionality plugin.

Please do let me know if this helps you in the comments, and stay tuned for a deeper dive into WP site performance auditing and fixes.

The tools you use, the way you want. Wrapping Help Scout in Nativefier

Posted on

One of the things we love about WordPress is that it lets us affordably build custom functionality into business’ websites that not long ago would have required tens if not hundreds of thousands of dollars invested in custom software development costs. Which is to say we think people should be able to have software their way.

Wrapping Slack “Making WordPress” in Nativefier

wp-core-slack-900x900In that vein I was delighted when Jason Cosper wrote last week about using Nativefier to create a mini app for the Making WordPress Core Slack Team.

Like so many businesses these days we use and have quickly come to rely heavily on Slack for our internal team communications. Increasingly however we’re also using it for external communications to keep in touch with specific groups, largely in the tech space but outside it as well.  I’ve heard of families starting their own Slack Team just to keep in touch.

Personally I belong to 14 Slack Teams: 5 WordPress groups, 7 non-WordPress technology and local community groups, 2! groups dedicated to just to coffee and a few others. It’s crazy.

One of those WordPress groups is “Making WordPress”, which is a massively huge group of over 10,000 members. It’s a vital communication channel though for everyone involved in the broader WordPress Community. Everything from Core development to organizing WordCamp events to updates to the WordPress.org website to securirty alerts gets discussed there.

Less to it’s core mission it’s both a great way to keep in touch with friends made at WordCamps as well as a great back channel between agencies working in the WordPress space.

Jason Cosper discovered the cause of something that had been driving me crazy the last few months with the native Slack app though.  It had become extremely unstable It was frequently crashing and taking up 100% cpu. That’s really frustrating when it’s something you rely on nearly every minute of your work day.

It turns out a big cause of that was including “Making WordPress” and it’s 10,000+ members in the native app. Jason removed that channel and wrapped it up in it’s own desktop web app using a new tool called Nativefier. It’s much like Fluid and what we called an SSB (Site Specific Browser) apps if you ever used those back in the day.  Since removing Making WordPress from my native Slack app, like Jason, I’ve found it to be much snappier and hasn’t crashed once.

The now isolated Nativefier app version of Making WordPress still gives me critical desktop notifications of direct messages, plus has the added benefit of staying out of my way most of the day. As you might imagine with 10,000+ members it can be a bit noisey.  It’s a win win.

Wrapping Helpscout Making WordPress in Nativefier

Nativefier-Help-ScoutIt occurred to me I could do the same thing with a few websites I like to keep open all the time. Starting with Help Scout which we use for tracking and responding to plugin support requests.

Steps for Mac OS X

Step 1:
Install Nativefier.

Ok, it’s a bit more complicated. You need to have Node NPM installed first, but if you’re a developer of any kind you probably already do have that. Then just at the command line:
npm install nativefier -g

Step 2:

Wrap up a web page in Nativefier, I did this in ~/Applications and then moved it to /Applications.

nativefier --name "Help Scout" "https://secure.helpscout.net"

Step 3 (optional):

It’ll grab the favicon by default, but his is often low res and ugly.  Replace it with a nicer icon.

I used https://iconverticons.com/online/ to convert a Help Scout PNG I scrped from their site into the ICNS format I needed for the dekstop app.  You can grab them here for Help Scout if you want: https://iconverticons.com/icons/93a786b5f69feea3/ or create your own.

Final Step:

Right click on the new app and select Open. You’re going to need to right click open on it the first time because it’s not an officially signed by Apple app, but you created it so you can probably decide trust it when the pop-up warning about it being untrusted comes up.

Now if the < 5 minutes it takes to go through those steps yourself is too much, or you don’t have NPM installed, or if your command line shy.  You can download my Nativefier wrapped up app of the Help Scout website here: Nativefier – Help Scout.

 

I can imagine others using this for Gmail, Calendars, all sort of things…  Let us know what you’ve used it for in the comments!