 Cool. Well, my name is Devin Walker and I'm going to be talking today about using third-party code to create unique and meaningful solutions. There we go. So when I first started developing, I wanted to do everything myself. I wanted to prove to people that I could build certain things that had already been done before. I wanted to have full control and after a while, you know, I figured that I was reinventing the wheel a lot and I started to question myself kind of like this velociraptor right here. Am I reinventing the wheel, you know, and a lot of times I was. So I figured it's better to save time and money while also giving your software the functionality that it needs. So this is where third-party code is really useful and you see it used throughout WordPress core, throughout almost any software that you use today. Third-party code is essentially a code that is developed by an entity other than the original developer or development team of the application or software that's being used. So third-party code can add a lot of value to your software. For instance, charts and reports, search. Search is a big thing. Elastic search is something that you're seeing come more and more into the WordPress world. Mapping, there's Google Maps. Everybody knows about Google Maps. There's Leaflet. There's OpenStreetMaps. There's lots of different options for mapping. Of course, Modals and Popups. These are just a few examples. You know, everybody's seen Modals. You click on an image. They can open an iframe. They can do Ajax requests. They can do so much complex functionality that it goes beyond just opening an image in a larger resolution. They can also save you time and money, like I mentioned in the title. For instance, we don't yet really have a Metafields API for WordPress. Hopefully it's coming soon, but we use a plugin called CMB2. Has anybody heard of that? Excellent bit of code developed by WebDev Studios. It allows you to create really complex custom fields in the front end or back end of WordPress. For all sorts of utilities, it has repeatable groups that you can create really advanced fields that if you were to develop that on your own, it would take a lot of time. It might not end up as good as they've developed. You'd have to support that code base yourself. Frameworks. Everybody's heard of Twitter Bootstrap. It's just one of the most popular frameworks for building either a web application or a website. Foundation is also very popular. SDK software developer kits. For instance, I have a screenshot here. It's really hard to see, but this is the Stripe PHP SDK. It makes it really easy to communicate with Stripe's API to do certain things like update customer records, to retrieve payment information, certain things like that. JavaScript libraries, jQuery. There isn't really a WordPress theme that doesn't use jQuery now. It's everywhere. To do simple things like expand a div or toggle an element, it's just one simple method. If you were to do that in vanilla JavaScript, it might not be as cross-device compatible, cross-bourser compatible, touch compatible. All these types of methods already developed in this convenient library for you, so why not utilize that? Make sure you choose these dependencies wisely, or third-party code wisely, because they can become dependencies. Once you develop and distribute your software, then your code depends on it. If you were to take that out, for instance, if you have a nice reporting analytics in your plugin, and you were just to take out that library that runs it, it's not going to work. Your plugin is dependent on that functionality. What to look out for when you're evaluating these different repos that you find on the Internet? Activity, Bitbucket and GitHub make it really easy to see what kind of check-ins and commits have been throughout the last year, time span. Stability, are they using semantic versioning? Are they properly tagging it? Extensibility, what kind of documentation, what kind of methods are there to extend the functionality of this code that you're trying to incorporate? And how popular is it? Popularity is an important thing. You can see the stars on GitHub, Bitbucket is very similar, as well as some of the other repos like Beanstalk. So what to ask yourself, is this supported? A lot of times, you know, CMB2, there was a previous version, if you decide to use the previous version, it's not supported, it's old, dead code. So make sure you read before you incorporate that into your software. How is it documented? Documentation is very important. The thing about, if I were to code a plugin and just pass it off without any documentation, a lot of people would be confused on how to use it. It would take time to discover exactly what's going on there. Are the regular bug fixes? Are they open to pull requests? If you need something and you want to contribute, are they willing to accept that or review it? How's the code coverage? Are they doing unit tests? Can you be confident in it? Is it secure? I mean, we've been talking about security a lot here. I went back and I added that because I needed to mention, you need to make sure it's secure because you can open your software up to vulnerabilities that you're unaware of because it's in a third-party plugin or something like that. Who else is using this? Make sure that there's other reputable companies or software out there that are also using the third-party repos. Will it scale? Is it going to bog down your performance at scale? And then who's behind this? Are these people that are known in the community or are they just, you know, nobody really knows who they are? So, two interesting tools for researching this. Open Hub is a great website. You can put in a repo. And this is CMB2, for example, and it gives you the number of commits. It says 1,400 commits. It gives you an estimated number of hours slash years that it took to develop it. It says it took, like, an estimated, like, 14 years to develop this plugin. I'm not sure how true or not that is, but it has 81 committers on it or contributors, excuse me. And there's also, it says it's, you know, 75% PHP. And as well, if you go over to the right here, this packages graph, it shows you who's using it exactly. Who's requiring that this plugin be used so you can actually see other reputable repositories and software that are using it. So, and make sure that you always check the license. A lot of times there will be a conflict in the license. Can this code be redistributed? Are you planning on releasing a plugin on WordPress.org with this included? So, you've got to make sure that the license is compatible with that. If you're trying to do something that's closed source, maybe a SaaS platform or a commercial product, you definitely got to read the fine lines because you don't want any legality issues down the line. And finally, keep me in up to date. As you develop your software, you're going to, you know, produce more versions, you're going to have more releases. And the same with these different repositories out there. So there's different tools like Bower, Composer, WB packages that allow you to require these dependencies. And by the way, if there is an update that's critical, you should make sure that you include that within your next release because you don't have vulnerabilities. And then you can use Gulp and Grunt, choose your flavor to compile and package it and also keep it up to date. Tom McFarlane is a great developer. I love reading his blog. He's, you know, pretty well-known in the WordPress space. And he's written about third-party code quite a bit and how that relates to developer maturity. And he says, knowing when to roll your own solution versus using the work of others is a sign of developer maturity. And that's why when I started, I said, when I first started out, you know, I kind of wanted to prove to myself and everybody else, my bosses, that I could hack this stuff. I could make it. I could develop it myself. But as I slowly, you know, progressed throughout the years, I realized that it's wiser to analyze the problem at hand, look for potential solutions, then determine whether it's the right route to go with a third-party code or to do it yourself. Thanks very much. My name is Dan Walker. I know this is a fast presentation, but it's a lightning talk. And you can find me online at Interwebs and this is a link to my slides right here. My main plugin is called Give. It's a WordPress donation plugin. We are the WordPress community consultants for MediaTemple and our company name is Wordpress. Here's all the links to all the repos I mentioned, some of the different utilities and further reading here, as well as Tom McFarland's blogs on dependency management and third-party code. And are there any questions? Wait, this one? No, no, that one. Look at me, okay. Thank you. We got there, we got there. Are there any questions? Yeah. Yep. Yep. Right. Yeah, you know, the documentation is really what's important to passing that to different developers. And as well, these third-party dependencies that you include in your software shouldn't ever really be touched and modified. Just like WordPress Core, it's kind of, you know, never modified. Everybody's heard that, you know? And the same can be said with this. And that's where extensibility and the different methods that they provide you to expand upon what their functionality is, whatever it is, it should be able to be picked up and passed off pretty easily. Does that answer your question? Kind of, yes. Kind of? Any more questions? Yeah. Can I comment on that? Yes. I just want to say that when you find that you get limits to the plugins, I'm sure that though the offer of that plugin would love for you to contribute to the thing that it doesn't have back to what you do eventually for your app. Yeah. That's a great thing. And in pull requests, you know, GitHub's making them easier and better now. I don't know if you saw that this last week. And as long as there are good developers, they're going to be open to those community contributions. Yeah. If I may add to that. Please do. Fix that code. Consider talking to that original developer paying him money to enhance his code to make it better. Money's great. Yeah. You know. Absolutely. Any more questions? Yeah. Yeah. You know, like I said, it depends on what you're doing and what you need functionality wise where it's going to be used. Willed scale. Is it secure? All that, you know, if you included Tim Thumb like four years ago in your, you know, library, you had a lot of security risks. And that's just one example. Of an exploit that was widely, you know, attacked. So I agree with you. I think you need to be very vigilant in what you code yourself. But again, I would say that you still are open to seeing what the community has to offer. Yeah. No problem. Reaching out to the author. And I'm amazed how fast they'll just email me right back. Give me what I asked for. Yeah. No problem. And I'm amazed how fast they'll just email me right back. Give me what I asked for. Sometimes charges minor amount. That does work. And then a question I have for you. The more complex the site, the more of these dependencies you're going to get, the more plugins you want to add. And then over time, these sites can be a real hassle to update. Yep. You know, you get buggy conflicts. You do an update, maybe one of the feature breaks because it's not compatible with the newest version or whatever. My question is, okay, how do you pose this to the client? And how do you build for your time? Do you have any strategies? You know, in the client's mind, I pay for that site. That site's done. It should just work forever now. Yeah. Well, you know, we go through that with clients, and then it's about educating them before you pass off the website. If you're going to be, you have a contract to build a site, and then it's their responsibility after that. You know, you have to explain to them, especially with WordPress, core that it needs to be updated. If things aren't updated over a large amount of time, you can be open to exploits and, you know, offer them the ability to manage that, you know, but it's not going to be free. Or you can point them to some of these, Maintain is a company, WP Site Care. There's a lot of these, now maintenance companies that will do it for a lot cheaper than an agency could do themselves. You know, you might be looking at a much larger retainer with an agency rather than a smaller one. As far as maintaining the plugins within your own, as a plugin developer, you know, we're always looking for the latest version of CMB2, see what they updated, see if it's compatible, and that's where unit testing really comes in to make sure your functionality stays in place if you do update a version that is a major release. Does that answer your question? I mean, so you approach it like a maintenance contract? Basically. Yeah. Definitely find who's going to be maintaining the site at the company that you're building it for, educate that person, and show them how to do updates themselves. Staging environments are always key for that, for sure, too. Well, upon reaching site, it says, oh, none of these plugins are registered on the site, then you can't do automatic updates, then everything gets out of whack, and then I've had a challenge with that. And on those sites, sometimes it seems you're just doing it in place rather than moving the staging. I'd be cautious with that, but, yeah. You can edit your hostess file through points, you know, www, www, your open machine, and then you don't have the problem. Well, but you still don't have those plugins are going to see themselves. They're going to see us? www, www, whatever it is? Yeah, you could always FTP it up, too. I mean... The minute that somebody wants a custom thing or a custom plugin, obviously, I'm not going to modify WordCent or something like that. Small plugins. It becomes custom, it gets changed, and it gets locked. 555 on the directory, and that's it, because if it's, you have modified, obviously it gets updated, then you're the thing, you can have your site break down, that's what he was talking about. So once you make a plugin your own, it's yours, you have to develop it, maintain it and everything, and simply, you may be with open for two or three years before you really have to rewrite it completely. But you just take a snapshot of it, and you will snapshot, and it becomes, just like a scene, you fix it, because if you get it, update, and you're bound to crash sooner or later. Yeah. Absolutely. Yeah, or that, or you know, a lot of these hosts, the premium managed WordPress hosts have snapshots that you can roll back to pretty easily. You might lose some data from the past day, but at least your site's back up. Absolutely. And back up off the same environment, do it offset, you know, back up. Yeah. Yeah, yeah, it's really easy for others to pick up and put down. Yeah. Cool guys, well, I think it's lunchtime, so let's get some barbecue. Thanks guys.