July 13, 2015

Apply Filters
Apply Filters
Episode 44 - Jonathan Christopher
Loading
/

Today we welcome Jonathan Christopher of SearchWP, Iron to Iron, and MondayByNoon to the show.  We also begin to explore WordPress 4.3 Beta 1 which includes updated password strength requirements, updates to the visual editor, and responsive list tables.

This episode was sponsored by WP Ninjas, the creators of Ninja Demo and the highly popular Ninja Forms plugin.

ninja-forms

This episode is sponsored by Dreamhost and their new Dream Press 2 managed WordPress hosting platform.Dream Press 2 is different from most managed WordPress hosting platforms in that it gives you two virtual machines (WebVPS and MySQL) for each site you have installed on the platform.  For more information, check out dreamhost.com/applyfilters.

DH_logo_blue-nopill

Today we welcome special guest Jonathan Christopher to the show.  Jonathan is author of SearchWP which is just about to celebrate it’s 2nd birthday.  He is also Co-owner of IrontoIron, a customer services company which builds custom products along with co-founder Kevin Richardson for small to medium sized businesses.  Jonathan also posts on Monday By Noon, which chronicles his journey as a WordPress developer.

Jonathan’s early days in coding went all the way back to Prodigy.  From those early days of the web he went on to school focusing on technology and eventually landed at an agency which is where he was first exposed to the world of WordPress.  As he says “he was hooked ever since” those first few projects with WP.

Bridging the gap between design and development is key in the evolution of any product creator. Jonathan usually starts a project with a good idea of what a UI will look like in his mind before he starts writing any code.  He believes this helps to make a more concise, easy to use product in the end for his customers.  Working every day with his co-founder, Kevin Richardson, is also really helpful as Kevin is one of the best designers out there.

Since launching SearchWP the biggest lessons Jonathan has learned have come around the topic of support.  Being exposed to the worlds of so many different types of paying customers has really expanded the scope of consideration in his products.  Continuing to try to do things “The WordPress Way” will set yourself up for success as it increases its compatibility with other plugins, themes, and core functions.

Currently SearchWP is a side project in Jonathan’s world, with his main focus remaining on client work at Iron to Iron.  He says that it’s likely to remain as such, and really does enjoy the client work he does with Kevin.

Hierarchy plugin is a great example of this.  In seeing customers having difficulty locating pages in their WP Admin dashboard, he created Hierarchy to have the backend better mimic the frontend of client sites.  This is insight he wouldn’t have gotten into usability without customer interaction through Iron to Iron.

Updates from Brad

    • Amazon S3 & CloudFront / WP Offload S3 0.9 released
    • Updating screencasts ahead of launch
    • Seriously working on solving a problem between migrating local and production databases.

Updates from Pippin:

Updates from Jonathan

    • SearchWP 2.6 was just released.  This includes custom classes that more closely mimic WPQuery.  The UI is also updated with v2.6.

WordPress 4.3 beta 1

    • Menus in customizer
    • Better passwords – Generate strong passwords
    • Editor improvements includes partial support for markdown syntax
    • Responsive list tables – the primary column can be set
    • singular.php

You can reach out to Jonathan on Twitter @JChristopher, check out SearchWP, or visit MondayByNoon.com

If you’re enjoying the show we sure would appreciate a Review in iTunes.  Thanks!

Transcript
INTRO: Welcome to Apply Filters, the podcast all about WordPress development. Now here’s your hosts, Pippin Williamson and Brad Touesnard.

PIPPIN: Welcome back to Episode 44 of Apply Filters. Today, we have a guest on with us. We’re going to talk about a few things around the WordPress world, including some recent updates and news, but first–

BRAD: This episode is sponsored by DreamHost and their new, managed, WordPress, hosting platform, DreamPress 2. I wanted to learn more about DreamPress 2, so I reached out to someone over at DreamHost who you may be already familiar with.

MIKE: I’m Mike Schroeder, and I’m the WordPress platform lead at DreamHost. I work both on developing products for or around WordPress like DreamPress, and they also donate about half of my time to work on WordPress Core and other related community projects.

BRAD: I asked Mike about DreamPress 2 and how it’s different than other managed WordPress hosting platforms.

MIKE: One thing that makes it a little bit different is that we give you two separate virtual machines that just belong to you, both a Web VPS and also a MySQL VPS. That Web VPS will automatically scale its resources for the RAM utilization needs that you have.

BRAD: Hang on. There’s a Web VPS, and what’s the other one?

MIKE: MySQL. Yeah, there’s a separate VPS just for your MySQL.

BRAD: Wow.

MIKE: And it has MySQL grade hardware that’s specifically engineered to work well with MySQL and that goes along as a companion to your Web VPS. Those resources aren’t shared between those two.

BRAD: And they’re not shared with any other customers or anything. They’re your VPSs?

MIKE: That’s correct, and you get a set of those. You get a set of those for each of your sites that you set up.

BRAD: Oh, wow, for each site. Wow.

MIKE: Yeah.

BRAD: Wow, that’s interesting.

MIKE: Yeah, so if you added two domains, you have four VPSs.

BRAD: There you have it, folks. You get two dedicated VPSs for each site on DreamPress 2. For more information, check out DreamHost.com/ApplyFilters. Now back to our show.

PIPPIN: All right, let’s jump in. Let’s go ahead and talk to our guest. Today, we have Jonathan Christopher, a pretty well known figure in the WordPress world, joining us. Jonathan, why don’t you say hi and tell us a little bit about yourself?

JONATHAN: How’s it going, guys? My name is Jonathan Christopher, as Pippin referenced. My primary focus in the WordPress world kind of spans a long time now, but my core focus is on kind of two companies I’m running, one of which is Iron to Iron, which is a client services company that focuses on building custom sites for medium to large businesses, and that involves kind of everything from project inquiry all the way to launch. That’s run by myself and my business partner, Kevin Richardson. We’ve been doing that since 2010.

My other efforts go towards a search plugin for WordPress called SearchWP that is going to be about three years old now this summer.

BRAD: Wow, really?

JONATHAN: Yeah.

BRAD: I would have said that you’re just celebrating, like, your first year anniversary or something.

JONATHAN: Yeah. It was kind of low key for a while there because it was my first venture into a product that I kind of stuck with. Actually, I’m going to take that back. It’s two years coming up this summer, so I’m losing track of time on it myself, but it did go by quick. But, I’ve kind of really taken it easy because I’m learning a lot about what is involved in kind of running a commercial product. As it goes with developers, I underestimated just about everything that has to do with it.

It’s going well, but I’m really taking my time with it because I rush into things from time-to-time, and I get really over-ambitious about things. I’m a husband and a dad, so I want to make sure that I don’t kind of get into that zone of freaking out about everything. It’s kind of run under the radar for probably the first year or so while I kind of worked out a lot of stuff that needed to get worked out.

BRAD: Right.

PIPPIN: Cool. I definitely have some more questions for you about SearchWP. It’s a really awesome product. I’ve been using it for a while now, and I really like it.

JONATHAN: Thanks.

PIPPIN: Why don’t we step back first, though, and let’s go back into some of your history.

JONATHAN: Sure.

PIPPIN: When did you start getting interested in development? Is it recent? Is this the last couple of years? Has it been a long time, early high school, before that? Why don’t you tell us a little bit about that?

JONATHAN: Yeah. My origins for getting into development go all the way back, honestly, to the days of Prodigy, which was before AOL. It was kind of like the first dial up service for the Internet, and I vividly recall hopping on there and just being kind of blown away about what I was looking at. I didn’t know what I was looking at, but something had me really interested in it.

Over time, AOL came out, and everybody got on AOL. I got really into the Warez scene on AOL, so my first endeavors into writing code were what were called punters or other things like that where you basically just flood people with instant messages. If your dial up connection was faster than theirs, you could theoretically kick them off AOL, and I thought that was the coolest thing in the world.

That kept on kind of nagging at me, and I was really getting into it. It was all Visual Basic, so I was really stumbling my way through it, self-taught and everything, but it opened my eyes to kind of building software to do things and even take advantage of writing software that works with other software, which is really weird to say, just like writing programs that just kind use and utilize other programs. In the case I was writing Visual Basic programs to work with AOL, like literally clicking buttons and things like that. That really just fascinated me.

That grew into some sort of way to want to talk about how I was working on these things. That grew into realizing there’s more to the Internet than chat rooms and AOL keyboards. There’s the Web itself, which didn’t take off as fast as AOL itself did. But, I eventually found my way into that, which opened my eyes to working with HTML. This was pre-CSS time, so I started tinkering around with building websites.

I ended up taking the only class in my high school that was offered in html, but I already knew all of the curriculum for the entire year, so I was just kind of working on my own projects during that class time. That kind of grew in further. At the time, for some reason, I didn’t realize that you could have a job building websites. I didn’t think that was a thing. For some reason, that never occurred to me.

I eventually realized that I had to have some sort of career path, so I naturally kind of just lent myself to IT because I kind of like networking. I didn’t think, for some reason; I don’t know why it didn’t occur to me that you could get a job writing code. I ended up starting my college career going for an IT degree, but quickly realized that I did not like the detailed intricacies of kind of building a network and what that looks like.

It’s interesting to me, but it’s kind of over my head and not something I wanted to keep on, so I eventually transferred to a different school and got into a degree program that was titled Information Science and Policy. That had to do a lot with language processing because half of the students in my class were going to be software developers, but the other half were going to be librarians. A lot of the classes had to do with linguistics and data mining, more or less, how you organize data, and how that relates to language.

It was really interesting to me, which kind of got me even more interested in that. Through that, I got a placement at a local library organization where I just kind of worked on their website, which is where I got exposed to CSS and actually working on kind of a team base, working on a website. From there, I got a job at an agency and stayed there for about five years. That’s where I really got hooked on building websites and building them for clients, specifically.

I spent a lot of time kind of evaluating what it looks like to work with clients and why certain relationships go really well and some go really bad, and how to kind of avoid those bad ones and focus on the good ones. That eventually led into me getting exposed to WordPress at that company. Kind of the rest is history. I was instantly in love with WordPress.

At that company, we had our own CMS that was really honestly ahead of its time, and it opened my eyes to content management, in general. I thought WordPress kind of aligned with those ideals, kind of sort of. This was pre-custom post types.

I saw all these things that the internal CMS would do that WordPress couldn’t, so that got me into thinking, “Oh, man. WordPress has awesome plugin architecture. How can I make it do what we’re doing in the CMS that’s proving to be too hard to maintain internally? I kind of want to get this company to move to WordPress because there are a lot of smart people working on it, and we don’t have time to work on this internal system.”

That got me into plugin development. I’ve written a plugins since then. My early ones were absolutely terrible, but it really exposed the community of WordPress, which got me in even more.

I started writing in my website, MondayByNoon.com, about what I was learning, whether it be front-end, WordPress, or what have you. That exposed me to the community of kind of Web designers, developers, and WordPress particularly. I’ve just been hooked ever since. Every year, I look back on what I did a year ago, and it embarrasses me, which is awesome because I’m still working on some stuff.

PIPPIN: That’s good. That’s a good thing.

JONATHAN: I’ve got a long way to go, but I’ve been tinkering around for a while now too.

BRAD: Right.

PIPPIN: Awesome.

BRAD: I find that your stuff is very well designed, which is not a given with programmers.

JONATHAN: Sure.

BRAD: Do you have a background in design, or when did you get interested in design?

JONATHAN: I’ve always — I would call myself kind of a want-a-be designer. I’ve always designed my own sites. I designed my own plugin UIs and things like that. I’ll try and remain humble when I say that I think I can put my mind in the mindset of clients who are going to use the software I’m writing, especially the UIs.

I don’t think my front-end design is anything to appreciate that much. It gets the job done, but I really like the problem solving aspect of making an interface easy to use and kind of not confusing because, as we’ve all seen, we know what a bad interface looks like. That really limits the success and usability of so much. It prevents projects from growing really well.

I think it’s one of the reasons WordPress has done so well is because–and a lot of people argue with this–I think, the UI is fantastic. I think, given the platform it provides, it’s a lot better than what else is out there, especially given how old it is. It’s been adapting to the crazy stuff we’ve seen built in WordPress for years now, and I think that’s just a testament to good thought and kind of sticking to basics when it comes to the UI of WordPress itself.

I guess it’s not something that I actively pursue. My partner at Iron to Iron, he’s one of the best designers I’ve ever seen, so I pick up on stuff that he’s doing, in a way, but we collaborate as well, a lot. I’m learning from him constantly, and I would venture to say that he’s learning from me too because we bounce a lot of ideas off each other and say, “Is this confusing? Are we just kind of doing this for the sake of being different, or is this just too clever for its own good?”

I think the underlying approach to it is just keep it as simple as possible, which I like that about WordPress too because Nacin has come out a number of times. He’s said, “Make decisions, not options.” That really hit home with me. I like to stick with that as much as possible.

PIPPIN: Yeah, absolutely agree. I like that you say all of that and then definitely stick to it within your own interface. SearchWP, I think, is a great example of a plugin that illustrates that mentality in its UI.

JONATHAN: Yeah. That was one of the first things. Honestly, with SearchWP, it’s weird. Some of the plugins I’ve written, and SearchWP is one of them, I actually started sketching the UI before I even knew how the heck I was going to build anything else. It just kind of started with: If I had a sweet search plugin, how would I want to configure it to match the features it has?

The big deal there was having fine-grain control over post types and what I call content types. Essentially what that means is like title versus the main content versus an excerpt or taxonomy or anything like that. How can I make it not a punch in your face, too many fields at one time? That might be part of it too where I balance the idea of actually writing code versus what it’s going to look like at the end of the day.

I think a lot of people might say that is not the wisest way to go about it because, as a result, your code might not be as clean and organized as it could be if you planned it that way from the beginning. But, again, I put a lot of value on the user experience of actually using, for example, a setting screen. I think that’s a big deal of it, sure.

PIPPIN: I think you’re a rare developer in that you have not only an appreciation for design, but you also have an eye for good design as well, both in code and interfaces. It’s definitely true that the way that a code base is laid out and organized, it has a very strong sense of design as well. Both your UIs and everything that you’ve designed into the plugin, on the website, and in your code, all share a nice, cohesive design, and that’s very cool.

JONATHAN: Yeah, I appreciate that. As I was kind of alluding to earlier, SearchWP is kind of the best that it’s gotten. I’ve had to resist the urge a couple of times over the past couple years. We all have a tendency to just scrap everything and rewrite it because there’s so much we would have done different, but I’ve taken cues from, especially you, Pippin, about how important backwards compatibility is and use that as a challenge.

Another thing that I heard from Nacin that said at one point, like, the code might not be beautiful, but if it’s working it might not necessarily be worth the effort to refactor it just because it could be written better. I’ve kind of taken both of those things to give me the freedom to iterate on things and not really wipe things off the table and just start from scratch because that’s, in a way, avoiding a challenge that I’m going to hit for the rest of my life. I need to know how to better iterate on things versus kind of wipe it clean and just start from scratch, so I appreciate that.

PIPPIN: I think small iterations is one of the most valuable lessons a developer can learn on a big project. Any time there’s a big project, and you decide there’s a feature that isn’t good enough or wasn’t designed well from the start, you have two ways of going about it. You can either rebuild the entire thing from scratch, or a big chunk of it from scratch, or you can slowly improve on it over time. I think, anybody that has taken the route of wiping it clean and starting over, unless you’re maybe lucky or exceptionally good, have probably discovered that iterating is significantly easier. Well, easier in a way, but has a much better end result.

JONATHAN: Absolutely.

PIPPIN: You have far fewer problems, you have less backwards compatibility issues, and you can do little chunks at a time instead of committing to this giant, giant rewrite.

JONATHAN: Yeah, it doesn’t feel overwhelming.

PIPPIN: Yeah.

JONATHAN: It’s nerve-racking, especially when you’re deploying these massive change sets to paying customers. You don’t want to mess with their life. You know what I mean?

PIPPIN: Those updates where you just cross your fingers and say, “Oh, I hope nothing goes wrong.”

JONATHAN: Yeah, exactly.

BRAD: What lessons do you feel that you’ve learned? You mentioned that you’ve been learning a lot with launching SearchWP, and you’re selling it as a commercial product. What are the things that you’ve learned from that experience so far?

JONATHAN: Well, I guess, primarily would be, most of the lessons learned are actually having to do with support because it’s different. This kind of ties into my client work. A lot of the stuff I’ve done and put out there for WordPress has been thanks to doing client work, number one, and then, now, working with paying customers because they think in so many different ways, and there are so many preconceived notions based on past experience, whether it be with a plugin or a past developer. I think my mind has been opened in a lot of ways to think about potential changes or implementations in that regard.

The biggest thing to take home for me was just continuing to do things the WordPress way all the more. What SearchWP, I don’t know that I consider it typical of your average WordPress plugin because essentially it’s kind of tinkering with a core operation in that it replaces native WordPress search results with what I guess I would consider better ones, for a number of reasons. But with that comes kind of how you do that and how it interplays with other code that’s out there, so meeting developer expectations was huge.

I think the first version of SearchWP was lacking hooks at all, which was kind of a showstopper because, immediately, people were wanting to do custom things, you know, “How do I do this? How do I do that?”

I started putting hooks in there, and then I started building extensions using those hooks. Then realizing that, with a good hook system in place, you can do things that you wouldn’t have even thought of before to do, but you can have it kind of in its own container and just utilizing hooks to make all that happen. I guess, kind of trying to think of it ahead and trying to think about how other developers are going to want to work with the code has been a huge learning curve for me.

PIPPIN: I think that’s a really, really, really important mindset that anybody that’s listening, if there’s one takeaway so far, listen to that.

JONATHAN: For sure.

PIPPIN: From a development perspective, I will share the same experience in that. Discovering how important trying to think about how other developers or other plugins want to interact with yours is huge for compatibility, for extensibility, for huge numbers of reasons, like, just trying to anticipate what people are going to do. If you can get yourself in that mindset, man, you can get yourself in a good place.

JONATHAN: Exactly, and it sets yourself up to, I think, at the end of the day, make your code that much more generalized, which I would wager; I would go on record saying that that, in the long run, is a good thing, as opposed to the other way around. You don’t have to kind of rewrite things to make it more generalized.

I think that if you go in expecting this array of post types to be filtered, for example, that’s going to kind of get your mind thinking about, okay, what else happens if this is now this post type I didn’t expect to be there? How can I make this code more adaptive and more useful in that case?

PIPPIN: Yeah, absolutely.

BRAD: I guess my question would be, if you’re just developing a new plugin, how do you even anticipate where these hooks are going to go? I don’t feel like you should go crazy adding hooks everywhere.

PIPPIN: That can get you in trouble too.

BRAD: Yeah, exactly, get you in trouble.

PIPPIN: We’ve gotten in trouble with EDD a couple of times because we provided a hook, honestly, where it turns out we shouldn’t have provided a hook because people used it, and then the ways that people used it made it so that we couldn’t change it.

JONATHAN: Ah!

PIPPIN: That’s hard, but I think that’s something you just learn from experience too.

JONATHAN: Exactly. Most of mine were in reactions to support requests, feature requests, or something like that. You’ve got to take all of those with a grain of salt because, in the beginning when I was first getting customers, they were asking, “Oh, can it do this?” Or, “It doesn’t work with this plugin.”

I was getting ready to write these code changes in core that cover this edge case in a plugin instead of saying, “No, add this to your functions.php, and it’ll handle it from here on out.” I was very quick to make impulse changes to the code. There’s maybe one of those that’s still there, and I just keep it there for pretty much that one person, but I think it’s important to resist that urge to just make a change to your code just to appease a customer when there might be a different way.

PIPPIN: Well, the same goes for better if you have a little discretion with implementing feature requests as well.

JONATHAN: Absolutely.

PIPPIN: If you just go in and put in every feature that’s requested, you’re going to, one, run out of time and, two, suddenly realize that you have this beast of a plugin that has morphed into something you had never imagined.

JONATHAN: Exactly.

BRAD: Right. In terms of, you mentioned reacting to support and adjusting your plugin based on support. I remember one of the things I was really impressed by in SearchWP was that it detected a potential incompatibility.

JONATHAN: Oh, yeah.

BRAD: Was that a result of customer support complaints and stuff, or how did that come about?

JONATHAN: It was, yeah, because, in my earlier, first few months of having the plugin out, there was what I assumed to be an issue with two plugins using the same hook at once. A lot of plugins — well, I wouldn’t say a lot, but a few of them using it in such a way that interfered with the way SearchWP worked, so I was just inundated with the support requests saying, “Search results don’t seem to be changing. I’m not sure what’s going on.”

One of the ways I would try to debug that was see what other code in their install was using these same hooks that I was, these kind of pivotal. There’s just one. It’s just pre_get_posts. That led to basically swap out anything that gets returned by wp_query. There were other plugins that were doing that, and trying to track that down was really a pain.

Yeah, I put out this message that would call out the specific usages and say, “You know, this isn’t necessarily a conflict, but it might be. You might want to check it out. But you might notice that, in subsequent releases, I’ve turned that feature off,” because I would say 95% of them were false positives.

PIPPIN: I wanted to ask about that.

JONATHAN: Yeah, so then I was getting inundated with ticket requests saying, “There’s this error message showing up.” It was caps, italics, bold, saying this is only a potential conflict.

PIPPIN: Oh, my God! What do I do?

JONATHAN: Yeah.

PIPPIN: We had the exact same experience with EDD. Everything that runs on the front end, like adding to cart, processing the checkout, etc., runs via ajax and runs through admin-ajax.php.

JONATHAN: Got it.

PIPPIN: Well, as you guys are both probably aware, every now and then you get a conflict where somebody has a security plugin that blocks admin-ajax, or they have HT access rules or something in there that prevents it from working. We implemented a check that attempted to detect if admin-ajax was open and could work.

If we detected that it failed, we showed an error message that says, “Hey. It appears that ajax isn’t working. This is not necessarily a problem. Here’s documentation about it. If everything works, dismiss this message and don’t worry about it.”

JONATHAN: Yep.

PIPPIN: The number of support requests we got from people just freaking out thinking everything is broken, ajax doesn’t work, my store doesn’t work, when in reality everything worked fine, was crazy.

JONATHAN: Exactly.

PIPPIN: We thought it was a great idea. We turned it off.

BRAD: Right.

JONATHAN: Yep.

BRAD: I guess you’ve got to get — yeah, like you said. If it’s an overwhelming majority of false positives, then I guess it’s not very effective.

JONATHAN: Right.

PIPPIN: I guess it’s one of those ones where you really have to try and figure out a way to maybe make it, like, 80% accurate. If you can do that, then I think it’s great. But, if you get those false positives, people react off the cuff too frequently.

JONATHAN: Exactly. Yeah. I did filter detection, but also, so a very common issue that happened for about the first year of support was these themes out there that would have redundant, either, calls to query posts or new WP queries on the search results template for various reasons. Essentially, the theme developer didn’t understand that, by the time you hit search.php, the search was already run. The posts are already there. You don’t need to run a redundant search query.

Normally what they would do is do that so they could get the total number of posts returned because they didn’t realize that’s already available in wp_query. They were just kind of doing it again. Essentially, what that would do is wipe out anything, any results SearchWP found, so the other check I have in place is that it actually checks the search.php template for any calls to wp_query or query posts.

BRAD: Query posts, yeah.

JONATHAN: There are some false positives because sometimes they’ll go through the main loop and then want to loop out–I don’t know–some other post for some reason. That is in there as well, but the chances of that being a false positive are greatly reduced because the need for firing query posts or a new wp_query on search.php is so rare. That one has been super helpful. I even call that out when you open a support ticket because I know chances are that’s going to be a solution to your ticket if you’ve blatantly ignored the warning at the top of the screen, which happens to date as well.

BRAD: Right.

PIPPIN: Very cool.

BRAD: That is cool.

PIPPIN: One more question about SearchWP before we jump into some of the recent projects that Brad, myself, and you have been working on, and then onto WordPress 4.3. Do you think SearchWP is going to become a full-time project, or will it remain as a very active side project?

JONATHAN: That is a question I’ve been wrestling with for a long time. I really love what we’re doing at Iron to Iron. I love doing client work, and I know a lot of people would never utter those words, but I attribute so much of the side projects I have, the plugins I’ve written, and the articles I’ve written to client work. It’s such an inspiration. Of course it gets frustrating from time-to-time, but I love working with Kevin. I think that not a lot of pairs of designers and developers can do what we do, so I can’t see that going anywhere any time soon.

I’ve kind of struck a balance with being comfortable with not going all in on SearchWP and putting all my eggs in that basket. I like where it is now. It’s growing, which I want it to do, of course, but it’s almost one of those things where you’d have to pry Iron to Iron out of my cold dead fingers, in a way, because I do love it. There are seasons where a project may kind of become overly stressful or something like that. But, once we’re on the next one and it’s new people, it’s a new product, new challenges, Kevin is doing an awesome new design, and I really want to build that thing out, and I want to see clients use the wp-admin, as I’ve set it up for them because they’ve never seen anything like it before, that is really kind of heartwarming to me, and it’s a very special place.

Honestly, I don’t see client going anywhere, and I kind of like moonlighting with SearchWP. It’s getting the job done. It’s really scratching my own itch because I use it on all of our client projects, and I think it’s helping a lot of developers. It’s something that I’ve wanted to build for, like, three years.

PIPPIN: It’s a great plugin to have around. I’ll tell you, at least from my perspective, you have competition. But, in the plugin world, I don’t think anyone has touched it.

JONATHAN: Yeah, so the competition is an interesting topic. There are, of course, the big names that have been around forever, which are doing great things, but there are all sorts of new, exciting things happening with search like hosted Elasticsearch and then companies like WP Engine kind of making it a bolt-on to your hosting service. I’m really anxious to see where search goes as far as WordPress is concerned.

But, I think SearchWP has something special because, honestly, the main thing I built it for was having multiple search engines, so you can kind of have your default search engine, but also one just for your doc section, for instance. That was a huge feature, but also, we’re using custom fields more than ever before. Being able to weight those on an individual basis per post type, I don’t really see that happening to a great degree with things like Elasticsearch, at least not yet.

I’m fascinated with Elasticsearch. It’s so killer. It does a lot of things that SearchWP can’t do, but I think there’s always going to be that place for SearchWP because there’s a barrier to entry to Elasticsearch, without question. I’d like to really just niche into that and see where it goes, I guess.

BRAD: That’s interesting.

PIPPIN: Well, cool.

BRAD: It’s interesting that you said that it’s rare to hear that people like client work, right? I agree it is rare, but I have heard it from one other person, which you wouldn’t expect because he’s very successful as well. Dan Cederholm, who is being Dribble.com, he still does client work despite the success of Dribble and his other ventures. He’s an author.

PIPPIN: I would not have expected that.

BRAD: Yeah.

JONATHAN: Yeah, I didn’t know that either.

BRAD: He draws a lot of inspiration from client work, just as you said. And so, you’re not alone out there. There are others.

JONATHAN: That’s good.

PIPPIN: There is something I will say that I miss from client work, and that is being able to work on highly specialized projects or very focused projects where I don’t have to worry about how what I’m building interacts with everyone else’s code in the world.

JONATHAN: Absolutely.

PIPPIN: That is a very cool freedom that we don’t have in the product space.

BRAD: Yeah, that is refreshing. That is refreshing, but I also agree with the inspiration thing because, with client work, you’re working on so many different kind of scenarios compared to when you’re doing a product. You can identify opportunities, I find, doing client work.

You run into a problem. Here’s an example. Jonathan, you have a plugin called Hierarchy, right?

JONATHAN: Mm-hmm.

BRAD: I’m just going to take a wild guess. That came from clients not being able to find their frickin’ pages.

JONATHAN: Well, in a way, yeah, but it goes back to kind of what I was talking about earlier. I just didn’t like the way that wp-admin presented managing content to clients. It felt very abstracted to me because the way I use custom post types is I kind of nest them under pages.

An example that I kind of go to is having an FAQ post type, but that’s probably going to be on an FAQ page or maybe even an about page or something like that. Going in and editing the about page in one place and the FAQ in another place, that’s like a main entry in the sidebar. That was very, very weird for me, so I thought it would be better for my clients to have some sort of better view of kind of their website as a whole.

One of my overarching goals with client sites is to make the admin mimic the front end as much as possible. That was a very latent kind of disconnect for me, so it’s kind of partially both. I just felt awkward presenting the finished site to a client and just explaining it. That part was awkward enough where I wanted to build this thing to make that process easier.

BRAD: Right, but if you had been focused on a product and not dealing with clients ever, you probably never would have bothered with that problem, right?

JONATHAN: Absolutely.

BRAD: Yeah.

JONATHAN: Yep.

BRAD: For sure. All right.

JONATHAN: Cool.

BRAD: Pippin.

PIPPIN: Let’s dive in quickly before we run out of time. Brad, you’ve got a couple of things that you’ve been working on recently. Give us an update.

BRAD: Yeah, sure. The Amazon S3 and CloudFront plugin has been released, the free version. We’ve released it, which means that the pro version is coming soon.

PIPPIN: Getting close.

BRAD: We do that staggered release thing. The free version that we just put out has been renamed to WP Offload S3, as well. I think we already talked about why I had to do that.

PIPPIN: Yep, a few episodes back.

BRAD: Yeah. Then I’ve been updating some of the screen casts and getting serious about solving the database merge problem that people keep coming to us with. That’s the problem where they have a live site that’s changing, and the local database that they’ve been working on has changed. They need to mash them together somehow.

We’re getting serious about solving that problem. It’s a doozy. It’s been already many hours, and I feel like I’ve just spun my wheels the entire time.

PIPPIN: Well, when you solve that problem, let the world know because that would be awesome.

JONATHAN: Definitely.

BRAD: Yeah, that’s what we’re here for.

PIPPIN: Nice. Good to have a global domination goal.

BRAD: Yeah, that’s right.

PIPPIN: In the last week, we started playing with something interesting. I’d love to hear you guys, if you’ve ever tried this with customer support. We decided, yesterday or the day before, to turn on live chat for EDD support, and just as kind of an experiment to see how it works.

We just put the live chat on the website. Then, if anybody has a question, they can pop in and ask at any time without opening a ticket. Have either of you guys ever experimented with a live chat?

BRAD: No, not really.

JONATHAN: No, me neither. I don’t know that I’d have the volume to justify it yet.

PIPPIN: It is nuts! It is. It’s actually pretty intense. We turned it on, and we get enough traffic to the site that if you’re signed into the chat portal as an agent, you have chats coming at you constantly. It’s kind of cool, but it’s also a little overwhelming as well.

We originally turned it on with kind of the idea that we have it there. We could answer a few presales here and there while working on other support tickets, development stuff, or whatever we’re doing at the same time, kind of multitasking. Nope, not even remotely the case. If you are in live chat, you are in live chat 100%.

BRAD: Wow.

PIPPIN: It kind of caught me off guard. We decided to experiment with it, and we’re using it for two weeks. Then we’ll see how it goes.

BRAD: Are you using Olark for that or something else?

PIPPIN: No, we’re using one called SnapEngage. It integrates directly with Help Scout, so we can turn a chat into a ticket any time we want.

JONATHAN: Cool.

PIPPIN: If we’re not online when somebody opens a chat, it can send them to Help Scout automatically. What I want to do is use it for two weeks and then look at our data and say, “Okay, did we resolve tickets faster? Did we have fewer tickets? Did we have more sales from this?” And see if we can make a data driven decision on using it.

BRAD: Oh, I see. You’re doing support and sales right now.

PIPPIN: Well, a little bit of both. The original plan was just for presales, but there are some actual support tickets coming through it as well. Though, we’re trying to, any time that somebody doesn’t have a ticket, unless we can solve it in a minute or two, we just say, “Hey, let’s go ahead and turn this into a ticket. We’ll create a ticket for you and get back to you.”

BRAD: Right.

PIPPIN: Which has worked pretty well.

BRAD: Yeah, it’ll be interesting to see how it goes.

PIPPIN: Yeah, it’s an interesting experiment. Outside of that, I also just pushed out an update for Restrict Content Pro, yesterday, version 2.2, that I’m kind of excited about because it added direct integration with WooCommerce to restrict the purchasing, as well as viewing, of a product to paid subscribers, which is really designed around the idea of if you want to run a club membership site, which I would not have assumed before is actually a pretty common request in e-commerce. Not just as, hey, let’s have someone purchase a membership and then download everything for free, but let’s have someone purchase a membership in order to be able to purchase products. I didn’t know that that was a really common thing, and it actually is, so we pushed that update out. I’m kind of excited to see where it goes.

BRAD: Neat.

PIPPIN: Beyond that, that’s pretty much my last two weeks.

BRAD: Cool.

PIPPIN: Jonathan, do you have anything that you’ve been working on recently that you’d like to share, either SearchWP or Iron to Iron?

JONATHAN: Yeah. SearchWP 2.6 just came out, and it’s got something in there that I’ve had on my mind for a while. 10up has this plugin that ties in. It kind of does what SearchWP does, but except it does it for Elasticsearch. One of the things that really stuck out to me that they did was, their whole goal was to support wp_query arguments.

I was kind of tossing that around in my head a little bit and realized that SearchWP is a little different because it has to have a custom argument at least for which search engine you want to use. After thinking about it a little bit, I decided to just kind of build my own class that was designed to mimic wp_query just because developers are so used to it. It’s super handy, and it would offload a lot of the complex implementations of hooks that would be required to do certain things like meta queries or tax queries and things like that.

So, 2.6 comes with a class SWP query, which supports a number of the same parameters that wp_query does, and it should make life a little better for a lot of developers, I would think, because the code is that much more clean. You can really do complex things, like I was saying, like meta queries, tax queries, and data queries, and all that neat stuff. It will just kind of utilize SearchWP to make all that happen. I’m really excited about that.

Also, this time, like we were talking about iterating, I’d always been dissatisfied with parts of the UI for SearchWP, so 2.6 kind of reworks that a little bit. It changes the way the setting screens are built and how the extensions tie in a little bit. That one is not as blatant as SWP query as far as usable things for developers, but I’m excited about the code being that much more clean.

BRAD: Cool.

PIPPIN: Very cool. It looks like an awesome class, the SWP query. It’s just super helpful.

BRAD: I have a question about SearchWP. We’re going to add related posts to the bottom of our blog posts on our site. I was thinking, maybe I could do that with SearchWP. Have you seen that before, or am I going to have to do this from scratch?

JONATHAN: That is on my extension wish list. I want to build an extension that will help you find the best-related posts. I’ve been rolling it around in the head, the logic to actually do that, because SearchWP has an index of all your content, but I’m struggling to nail down how it should determine what search terms to use to find those related posts.

Many of the related post plugins out there, you can weight the tags or any taxonomy or something like that. That feels a little arbitrary to me. I’d like it to be kind of automagic because that’s kind of how SearchWP works. I’m thinking of ways to kind of evaluate the index to find the unique words in a post that you want to find related posts for.

For instance, if you write a post about some sort of topic, it will actually query the index to find out which words are the most unique to this post and use those as the terms, but I haven’t fleshed that out yet. It’s really just a sketch on paper for now. Unfortunately, that’s on you at this point.

BRAD: Awesome.

JONATHAN: Yeah.

BRAD: What if you could just input the search terms in the backend when you’re–?

JONATHAN: That’s an idea.

BRAD: Then it would give you a list of, like, the related posts that it picked out. Then you just said–

PIPPIN: Just to find your keywords.

BRAD: Yeah.

JONATHAN: Yeah, that’s a good idea too. Nine times out of ten the title itself will work well for that.

BRAD: Right.

JONATHAN: Yeah, I’d love to get something out there because, you’re right, it’s kind of a good platform for that. It could work really well. There’s this really killer related posts plugin that came out recently that seems to be working really awesome, so I kind of backburnered the extension idea for a little while there, but I should get back on that.

BRAD: Yeah.

PIPPIN: You know, Brad, you could do that pretty easily by just you registering your meta field, add in your keywords, and then just dropping an SWP query into your template with your keywords.

JONATHAN: Yep, that would do it.

BRAD: Exactly what I was thinking.

PIPPIN: Sure. That’d be cool.

BRAD: Yeah.

PIPPIN: Nice. I like it.

JONATHAN: Yep.

BRAD: You mentioned the related post plugin. Yeah, I’ve been looking at that.

PIPPIN: Is that Barry’s or a different one?

BRAD: I’m not sure who did it. I think it’s RelatedPosts.com or something.

PIPPIN: RelatedPostPlugin.com? Yeah, that’s Barry’s.

BRAD: That’s Barry’s? Okay. It looks amazing, right?

JONATHAN: Yeah.

BRAD: It just doesn’t make sense to me to have that and SearchWP. They’re basically both creating an index.

JONATHAN: Yep.

BRAD: It just seems redundant.

JONATHAN: Sure.

BRAD: Anyways, should we move on to WordPress 4.3, beta 1?

PIPPIN: Yeah.

BRAD: Cool.

PIPPIN: Let’s see. Beta 1 got released just a couple of days ago. Have either of you guys played with it yet?

BRAD: I haven’t.

JONATHAN: I’ve just read kind of the breakdown of what’s been added. I’m pretty psyched about a couple things, actually, to be honest with you.

PIPPIN: Cool. What excites you about it?

JONATHAN: First thing first is that it obliterated a plugin that I’d written, which I love. I love when something I’ve written kind of gets absorbed into Core, even if I didn’t contribute directly. The whole thing about creating a new user and, instead of emailing them the password, it will email them a password-reset link, which is genius.

PIPPIN: Yes.

JONATHAN: I love that idea. A lot of effort went into password stuff, but I had written a plugin that would do that. Specifically, the need came up with SearchWP because I needed to create manual purchases for some reason. As a result, I needed to create user accounts.

I didn’t love the idea of manually resetting. I started out by just kind of manually triggering a password reset for them once I created the user account, but I wrote this plugin that was just a checkbox that said, you know, email them a password reset link when I create the user. But now that it’s rolled into Core, that’s even better. I love that part about it.

BRAD: That’s funny because I actually built this too.

JONATHAN: Did you?

BRAD: We have this as part of our site right now. Our checkout used to ask for a password. I was like, well, that’s just another thing they have to do in a checkout that they might abandon checkout for, right? We got rid of the password fields, and we just email them a reset link for them to define their password after the purchase.

JONATHAN: Yep.

PIPPIN: That’s smart.

BRAD: Basically, the same kind of thing, right?

JONATHAN: Yep, exactly.

BRAD: Does EDD do that? Does it ask for a password on checkout?

PIPPIN: It does if you create a user account, which is determined by whether or not you make your store require user accounts.

BRAD: Right.

PIPPIN: You can control that. That’s a cool feature that I had never actually considered doing. I think it’s just kind of engrained in systems for us that if you create a user account, you specify a password.

JONATHAN: Right.

PIPPIN: Brad, you’re absolutely right that there’s no reason you couldn’t just auto generate one and then send them a reset.

BRAD: Yep.

PIPPIN: And make checkout easier.

JONATHAN: Mm-hmm.

BRAD: Yep.

PIPPIN: Smart. I’m really happy with the password updates in 4.3 because, along with not emailing the passwords to users, it’s also giving us the ability to generate a password for a user account and not know what it is, and generate a strong one just with a button that says, “Generate Password,” which is fantastic. I believe that was carried across onto the “Add New User” screen, the “Edit User” screen, and possibly even the brand new “Install” screen for a brand new WordPress install for the first admin account.

JONATHAN: Oh, cool.

PIPPIN: This is one that’s very close and dear to me because I didn’t actually work on this implementation, but I did a lot of work kind of proposing this change, originally. There’s a great plugin by Jake Goldman from 10up, basically, that added this feature. I’ve been using it now for probably two years. Since I had several sites that were very user account heavy, I had to reset passwords all the time, and so seeing this in Core and not having to worry about it in a plugin anymore is excellent. Maybe we can get away from the admin/1234 accounts that we see in customer support all the time.

JONATHAN: Exactly.

PIPPIN: Let’s see. What else is new? We’ve got menus in the customizer. Maybe we should not touch on this.

JONATHAN: Agreed.

PIPPIN: They’re there, whether you like it or not.

BRAD: Is that a point of contention?

JONATHAN: Oh, brother.

PIPPIN: Man, you have not been paying any attention for the last….

JONATHAN: I need your focus, Brad. I need your focus.

BRAD: I try not to pay attention.

PIPPIN: Don’t worry. Yeah, a lot of people are really unhappy about menus being put in the customizer. I had mixed feelings on it. I will say that the first time I saw them in the customizer when testing a beta, it actually didn’t even occur to me what I was seeing because it just kind of worked, so it was fine. I think the implementation is nice. I think it’s smooth. If you don’t like it, well, go improve somewhere else. Go improve something else.

BRAD: Use Squarespace.

PIPPIN: Well, I don’t mean it that way. I mean more like, if you’ve got things that you really don’t like, put your effort into improving it. Put your effort into either improving what you don’t like about the implementation or put your effort into helping in another area. Don’t just bitch and moan. That’s all I’ll say there.

Let’s see what else. There is another improvement that I really, really like: improvements to the editor. Are either of you guys a fan of Markdown?

JONATHAN: I was just going to bring this part up. I love it.

BRAD: Whoa!

PIPPIN: Sweet.

BRAD: Cool! We use Mark Jaquith’s Markdown plugin already.

PIPPIN: Yeah, so you see what I’m talking about, this change. What it is, is actually the WordPress text editor now automatically detects certain text patterns. If you’re familiar with Markdown, you know that you can use asterisks, hyphens, and greater than symbols for a few formatting things like unordered lists, ordered lists, block quotes, headers, etc.

Well, these can now, which all come from Markdown, but they can now be used in the normal visual editor to automatically format your content. If you want to make an unordered list, just put a hyphen before each line and WordPress will convert it for you. I think that’s awesome.

JONATHAN: Yeah, it’s killer.

BRAD: What if you don’t want it to convert?

PIPPIN: Yeah, I don’t know about that.

BRAD: Does this have full Markdown support? Is it going to work with images?

PIPPIN: I think it’s just partial support. I don’t know.

JONATHAN: Yeah, just a few select things, it looks like.

BRAD: Okay.

PIPPIN: Yeah. Looking at the track ticket, I think it’s just — oh, here we go. They actually have updated. When you’re in the editor, you can actually click on the keyboard shortcuts to open a modal window, and it will tell you the shortcuts available. They listed them all there, and it looks like it’s headers, block quotes, and lists. Anyway, I think it’s a super cool enhancement, and I’m sure there are going to be cases where people don’t want it, and so we’ll probably have a plugin that will disable it, which is cool.

JONATHAN: Yeah, between this and the recent change where you can kind of highlight text and, when you paste a link onto it, it turns it into a link, that really makes….

PIPPIN: I did not know about that.

JONATHAN: Yeah. If you highlight text, and you have a URL on your clipboard, and you paste it on that highlighted text, it will automatically make it a link.

PIPPIN: That’s awesome.

BRAD: That is neat.

JONATHAN: Between these changes and that, I mean, media integration is really sweet because you can now drag. You don’t have to click “Add Media.” You can drag right on TinyMCE, and it will drop it wherever the cursor is.

PIPPIN: I was using that this morning. It’s awesome.

JONATHAN: Yeah, I love Jacquith’s plugin as well, but this is really neat too. It’s kind of a hybrid between the two. It’s almost the best of both worlds, so I’m really anxious to see how it plays out.

PIPPIN: Yeah, definitely. There are two other changes that I think we should mention here before we wrap up. The first is list tables are now much more responsive and better for small screens. This isn’t just Core WordPress tables. This is also all list tables in plugins. If you have built a list table that’s using the WP list table class, or if you have built a list table by hand, I think, as long as you followed the correct html and the proper classes, it will automatically get truncated down to just one column on a mobile view with then an option to expand it, which is kind of nice.

BRAD: I worked on that a little bit.

PIPPIN: Did you?

BRAD: Yeah, with Helen and Ryan Boren.

PIPPIN: Awesome.

BRAD: I was just kind of back and forth with them a little bit, but yeah.

PIPPIN: I really like the change.

BRAD: It was tough. It’s a tough thing to do to get.

PIPPIN: Yeah.

BRAD: Because you can’t have all the information on a phone. It’s just too much.

PIPPIN: Then there’s another issue. This goes into a developer change that’s pretty important to know about if you build custom list tables. Like you were just saying, how do you know what to show? How do you define? How do you know what the primary column is? Just because you have ten columns doesn’t just mean you can show the first one.

BRAD: Right.

PIPPIN: How do you do that? What they’ve done is they’ve actually created a way to specify a primary column. Whatever the primary column is is what will be shown on a small screen.

BRAD: Huh.

PIPPIN: I helped out on this one a little bit. Mostly Helen pinged me just to test it because I’ve done a lot of list tables in a lot of different plugins. What do you do if you don’t have a primary column specified? The answer was basically let’s just take the first table, the first column that is not a checkbox.

BRAD: Right.

PIPPIN: But it’s good to know because, if you have a plugin that uses list tables, you can now go specify a primary column if it’s not the first one.

JONATHAN: Nice.

BRAD: Cool.

PIPPIN: Which is definitely a good thing to do. There’s one other change. Well, several other changes. The big one being taxonomy stuff that we mentioned in the last few episodes, so we don’t need to cover that. Singular.php, Brad, do you want to tell us about this one?

BRAD: Not really. I kind of remember. I get the emails from, like, the make blog, and I remember seeing this one. It has something to do with custom post types, right?

PIPPIN: Right.

BRAD: I think it’s any custom post type will fall through to this new template, singular.php, for the single page, for the single post page.

PIPPIN: I don’t remember if it’s every single post type or every post type that is defined as hierarchical.

BRAD: Oh, so maybe I misunderstood.

PIPPIN: Well, we have the helper functions: is single, is singular, and is page. Is singular is for detecting hierarchical post types, which is most custom post types because I think the hierarchy is enabled by default. Basically, anything that will return true for singular, for is singular, will now land on a template called singular.php.

BRAD: Okay.

PIPPIN: Then the fallback being single.php and page.php. It’s just another one more piece added to the template stack, which I know a lot of people were very, very happy for. I think the main reason that a lot of people were thrilled with the change is for consistency sake because now our template functions that we have, like is single, is singular, is page, is taxonomy, is term, etc., those now all follow the same function, so we have a function for each template. Sorry, we have a template for each function.

BRAD: Yeah.

PIPPIN: There’s a one-to-one correlation now.

BRAD: Yeah, that makes sense. That’s a good way. I’m glad you explained that to me because I was kind of like, I don’t know what this is for.

PIPPIN: I could be wrong. If anybody has a strong opinion on singular.php going in, good or bad, and you disagree with that, I’d love to hear about it, but that was my understanding of it.

BRAD: Cool. Should we wrap it up?

PIPPIN: Cool. Yeah, I think that’s about it. Jonathan, thank you for coming on. It was a pleasure.

JONATHAN: Yeah, thanks for having me, guys. You guys are a big influence on me, and it’s honestly an honor to be here. Yeah, keep doing this podcast.

PIPPIN: Glad to hear we could help.

JONATHAN: One of my favorites.

PIPPIN: Why don’t you, real quick, tell people where they can find you, how to get in touch?

JONATHAN: Sure. Yeah, Twitter is @JChristopher. I’m trying to publish on MondayByNoon.com as much as possible. SearchWP.com and IronToIron.com are pretty much keeping me busy.

BRAD: Yeah, I bet.

PIPPIN: Fantastic.

BRAD: All right. Thanks, everybody.

PIPPIN: All right. Thanks for coming on and enjoy your days, everyone.

Apply Filters © 2024