Hello. Thanks for joining me on the webinar today. Great topic I have planned for you today. We're talking about WordPress, and specifically WordPress management. You know, we all know that WordPress is a very popular content management system started ... its roots were back as just a blogging engine for hobbyists, really, and today controls up to a third of the internet. One of the things I've noticed about WordPress recently is it's just going more and more into enterprise environments. Enterprise, to me, I define it as an environment of relatively high stakes. Businesses depend on it. You might be running commerce applications. You really can't afford downtime or security breaches or things like that.
Today's webinar we're going to talk about two things. Number one, how do you properly deploy WordPress in this type of environment? What are some of the things you can do to kind of take some of the risk out of the equation for you? Number two, on an ongoing basis, what do you do to maintain the platform? While it is the most popular and it is very easy to use, marketers love it, it is the most vulnerable. It is the most attacked. Part of that is because of its popularity. Thanks so much for joining us. Thank you to everyone who pre-submitted questions. I'm going to get to them near the end of the webinar. Again, if you have any other questions, you can just send them over on the ... on that side of the screen. Thanks a lot. Let's get into it.
Let's dig right in. Thanks again for joining me. Today's agenda, going to tell you a little bit about who we are. I'm going to talk about WordPress and the platform, maybe some of the history, talk a little bit about as a multi-phased approach really that I look at WordPress Management as being, you have your pre-deployment, deployment, and then you have your ongoing. We're going to talk about both of those things. Looks like a simple agenda, but I assure you there's quite a bit to discuss here.
First off, about us. We've been in business since 2001. Again, my name is Peter Czech. I'm the founder of the company. We are a full service agency. I know that's such a cliché term at this point, but we really do specialize in these services that you see on the screen in front of you, so strategy. We work hard on architecture, developing projects in terms of how they're going to work doing discovery. From there we work on design, front end design, UI/UX development, back end development, lots of custom development work. Then, also, ongoing maintenance, which is ... consists of keeping things running 24/7, monitoring, things such as that, and continuous improvement, which we're going to talk about in a little bit as well. Of course, also marketing services, lead generation, content marketing, all things that we do.
Proceeding through. Who are you? I have a pretty diverse group of people that have joined today and signed up. Thanks so much for doing it. We have everything from Fortune 500 marketing personnel to small business owners and marketers for small business, a couple students. Good for you for signing up, trying to learn a little bit. Hope I can teach you a couple things. Then, we have other agency people. Happy to have you as well. Thanks for joining us. Like I said here in this note, the diversity of the people who signed up is really indicative of just how broad the usage of WordPress is. Again, welcome and let's get right into it.
WordPress, it's been quite a ride. This is a platform that's been around for quite a while at this point. Just recently, really, has it seen this explosive growth. By recently I say over the past seven or eight years. Started, again, as a blogging engine. Became pretty much a CMS powerhouse at this point. If you look at this chart, this is provided by BuiltWith, you can see just what the explosive growth has looked like, to the point where, today, it powers 33% of the web, which is crazy for one system to be able to do that. That's 22 million, almost 23 million sites. It's quite a footprint that it's built for itself.
Today, where really I take interest in what's going on with WordPress is it's going into the enterprise, into larger corporate environments. I think part of the reason is younger marketers, people that grew up with it, maybe did some little side projects or some hobbyist type stuff. They came into decision making roles and they're comfortable with it. I think that has something to do with the growth that we've seen. Sorry, I'm looking out the window here. I see my art director's walking his dog out there. It's also getting harder to justify these massive license fees and implementation costs. We're going to talk about license fees in a couple of slides. Just so you know, WordPress is free. It's not free to maintain it. It is free to get the software and license it. It's getting harder to justify, hey, $40, $50 thousand for some of the enterprise quality software that's out there.
The other thing, too, where it's getting a little bit more accepting is open source in general is pretty much mainstreamed. People have seen startups go and build on open source and grow it into massively scalable applications. Facebook, Google, they've all built massive applications on top of open source. It's become more acceptable and all these things together have led towards WordPress breaking into enterprise environments.
The economics. I want to talk about the economics of CMS systems if I can for just a bit. On the high end, you have your systems like ... and this is not, by any means, a comprehensive list. On the high end you have, in the enterprise, AEM, Adobe, mid six figures on average. Implementation costs on top of license fees, you're looking at million dollar projects. Then you go down to something called Sitecore, very popular, enterprise-friendly, $40, $50 thousand over the course of the first year, and then ongoing yearly fees. Then in between that and getting down to what I ... what are called headless providers, there's just tons, tons of other options there as well. Headless providers are a very interesting case. It's a new technology. I hope to spend a little bit more time talking about it in the future. We are doing some work in the headless area. Those are ongoing license fees, which can add up to $30, $40 thousand a year.
You have these enterprise level pieces of software. Then you have this open source stuff, which is free. It's free to license. You can take it off the shelf, amend it, pretty much do whatever you want with it. That's where WordPress, Drupal, Joomla, they all play in that area. Just because it's free, though, I want you to know there is a cost. It's free to license. It's free to go and install it yourself, but it's not free to implement. It's not free to design. It's not free to build on top of it. Then there's maintenance and management. We're going to talk about this in a little bit. WordPress, the project and the company that maintains the project, automatic, they actually have WordPress VIP. I have a blog post that explains that. At the high end, they charge $300 thousand a years to maintain WordPress. At the enterprise setting, you're going to be spending no matter what. I think that people are shocked when I say that, 300 thousand, but that is the number.
WordPress off the shelf, and again we're going to talk only about WordPress. I diverged there a little bit from the topic. WordPress off the shelf, you can't just take it, install it, and expect it to work in the enterprise. That's not the way that it works. It needs a lot of configuration. It needs a lot of configuration pre-deployment. You need a reliable maintenance and continuous improvement plan. If you have those things covered, then yes, it can be suitable in an enterprise setting. That's what we're going to talk about today. Again, I look at things in two phases when it comes to WordPress. I look at, number one, initial implementation. This is your planning, the development, and the deployment of your project, everything that happens before the public even sees it. From there, I talk ongoing maintenance and management. We're going to talk about these two phases today. Let's dig right into it right now.
First, implementation. This is a very loaded term. This is more than just installing it onto a server. Implementation really covers the depth of an entire web project. I think it includes your strategic beginning, the architecture, the information architecture, content layout. It involves, obviously, content planning. I have that here as a note. Then into design, UI/UX, development and then eventual deployment. All that goes into implementation. There's a lot there. For the purposes of today, I'm not going to focus on that part of building out a digital project. What I am going to focus on are some strategic choices you can make before deployment so that, from a long term perspective, you have a stable build out of the platform.
With that, the first thing pre-deployment that you should do is a security sweep. This is so important with WordPress. Unfortunately, WordPress is a great platform, we know it powers a third of the web, there's no disputing these facts, but with popularity comes the downside of it becomes a target. Most of the time when you see security problems with WordPress it's automated bots that are just hitting it over and over and over again, trying to take advantage of it. The reason that they do that, again, is because there's just so many sites out there and so many possible victims. This is why we're going to talk about updates and upgrades and all those things in a little bit. You do that to try to prevent some of these security flaws from coming back and biting you in the butt, for lack of a better term.
It's essential that, before you deploy, you thoroughly scan the site for any security concerns. I break it into two checklists at this point. For those that are do-it-yourself, there's things that you can do. Then there's stuff that you really need development help with. I'm going to bang through the list pretty quick here. If anybody wants a list, I'm happy to send it to you. Just email me or leave a comment right here in the system. A couple things you could do yourself. Practice safe password management. Shouldn't really have to say that at this point, but a lot of people put in pretty simple passwords. If you think about it, if someone tries to brute force their way into your install, let's say you're running commerce, let's say anything with user data, that's very dangerous. Not only for yourself but ensure this across the company, that there's a level of responsibility in picking passwords.
Another thing you can do is simple yourself is getting rid of the default admin username, kind of like a no-brainer. If someone's out there just attempting to get in, they're going to probably try that admin username, so cut it out. I'm talking to you. Cut it out. Not anybody over there. One other thing you can do, verify your plugins are reputable. This is kind of like a no-brainer type of thing. You should be able to do it just by doing a little bit of research. Some plugins are much more reputable than others. There's a ton of SEO plugins, but Yoast everybody knows is the best. There's a ton of form management plugins, but Gravity Forms is great. If you're going to do commerce, WooCommerce is run by Automattic. These are relatively simple to vet. Definitely do that.
Getting into some more advanced topics, and this is, again, not even a comprehensive list, but a couple things that are relatively easy to do if you have technical knowledge. First thing, utilize SSL. That's HTTPS. This is a no-brainer. You should be doing it. Google's pretty much telling everyone if you don't have it that you're not secure. You should set that up. You might need help from your host, though, or a technical person to do it. Disabling FTP. FTP is inherently insecure, so you probably shouldn't be using it. Use SFTP instead. Without getting into the technical knowledge of it, I don't even know how I could do that in 10 seconds, but it's a much safer way to go.
Try to change your WP ADMIN. Everybody knows yourdomain.com/WPADMIN is where the administrative portal is. Try to conceal it. Change the name. Try to conceal as much as possible about WordPress. Try to conceal the version that you're on. If people can determine your version, then they know if you're up to date or not. Then they know ... they don't know to go looking for holes and gaps. Another thing, consider two-factor authentication. A lot of services use that today. You probably use it other places. Someone can install that for you. There's plugins that do it, reputable ones. Consider auto logging people out. There's plugins for that, so that if someone's ... leaves it logged in and let's say they're at a café or something, or computer's stolen, that's a good way to just make sure that they're automatically logged out.
This one's a little bit more technical. Obviously there's a MySQL database that powers WordPress. Eliminate the prefix that every table is named with: WP_. The reason that you do this is so that if someone manages to install a script that messes with the database and it's hard coded to look for WP_, the script won't work. Something to think about. This next one, cross site scripting, SQL injection, cross site request forgery, things that are a little bit more technical, but I put it here hoping that you will go and talk to your technical person about it, make sure you're covered for these things. What else? Another thing, disallow file editing. Obviously, inside of WordPress you can edit files that are part of the theme. Disable it. Disable it. If you have technical help, you shouldn't be doing that anyway. Then, finally, checking directory permissions throughout the install, something that us admin can do for you, just prevents the ability for people to upload files, place files in certain spots, and then execute, make them executable. These are all things you should definitely consider.
With that said, another thing that you should do is install security scanning software. These things are really essential at this point. I like WordFence. It's my preferred vendor, but a lot of guys do it. Sucuri is one. I think it's SiteLock. Maybe that's another one. Take a look at that. Just beware. Even though you have these and some of them even have cleanup services, you're really kind of on your own. I would be very careful about engaging with them or hitting any buttons that do automatic clean up. That's when things kind of get a little bit out of control. Either way, do install that software. It's very important.
I'm going to go into hosting. I want to explain that. That's a big pre-deployment thing to consider. I'm calling this getting capable hosting. There's three major buckets of hosts that you could choose from. You have your shared hosting. There's a lot of people that do that and I'm going to get into it. You have WordPress managed hosting. Then you have self-service, dedicated instances like a RackSpace or AWS.
Really quick, digging into each starting on the low tier with your shared hosting. Very old school model, still very popular. These are your two dollar a months or your free hosts. If you're an enterprise setting, we shouldn't even be talking about this, but really quick. The pros are price. Depending on the provider, you might have some support. They might go and answer. Those are relatively good things. You have no control over the software that's running on the server, pretty much none. There's major speed issues and that is mostly because of shared resources. If another site on the server is hacked, that places you at risk but it also lowers your performance. Overall, you get what you pay for. I don't really recommend this. I do see enterprise companies ... I have companies that raise more than seven, eight figures in funding and run GoDaddy, so I've seen it. I don't recommend it.
The next step up, which is a good step, is managed hosting. This is something that's more specific to WordPress. There's companies that do it for Drupal and other platforms as well. Pros are it's mid-priced, maybe less than $100 a month. You get pretty decent support, people that understand WordPress. It fixes a lot of the common WordPress concerns. WPEngine, I put them as the only one because they're really good at it. They're maintained, I believe, by automatic as well. Common concerns: running dev environments, certain security things, they're going to take care of that for you. It's a pretty good and capable platform. Some of the cons, again, you could be sharing infrastructure. It's going to push you to maintain currency, which means that they're going to make you update, even though you may not be ready for it. You're going to lose some flexibility along the way. Not a lot, but some.
If you want to build a custom plugin or build some custom functionality you can do it, but it's not going to be as strong, the access that you would receive with a dedicated server instance. Some of the technical aspects you really don't know, so you don't know how it's going to scale even though they make assurances. I put overall, you get what you pay for. Well, you do. You're paying a little bit more again. It's a decent way to go. I definitely see organizations running on WPEngine. We have quite a few clients who do it. It is reputable.
This is the self-service dedicated instance model, your third option: AWS, RackSpace. Basically, what you're doing with these providers is installing a server box for yourself, but it's virtualized. Back in the day, you used to get an actual 1U/2U server that you would lease. It's not like that anymore. Everything's virtualized. The pros here are tons of flexibility. You run the server, so you can install any software that you want. Scalability, I like this model because I can always go and instantly upgrade a server to give it more memory, more drive space, more processing power. That happens relatively quickly and seamlessly. I think you have a lot more control over scalability, tons of control. It's your server. You're installing the software. That's a pretty important thing.
The cons. This requires maintenance and upkeep. When you have a server running, you have all the software underneath that you need to maintain. It's pretty much self-service, other than Uptime. If you go them and you say, "Hey. There's an issue with deliverability," they'll check it up to the server, but they're not going to go further unless you have some sort of other agreement with that company. Also, you need technical knowledge. You're not going to be able to do this by yourself. It's going to be very difficult. Again, you need to keep it updated. That's going to be challenging today if you're not a sys admin. Overall, I think this is the best for enterprise environments. The cost is relatively low. You could run a WordPress site for under $100 a month and have a lot of firepower to keep it going. We definitely do recommend this as the best way forward for enterprise settings.
I think this is the last step. Installing monitoring, I mean, this is so important. One of the great things about using AWS or RackSpace is the ability to install software that doesn't just look to see if you're up or down, but also looks to see is your memory usage high, is your hard drive getting full, how's MySQL performing? Monitoring is essential no matter what. I like the dedicated model 'cause there's just so much software you could install. Nagios is a great platform, something that we utilize. You're not going to be able to do that with shared hosting. Shared hosting, you're pretty much looking at Pingdom or some other third party tool that tells you are you up or are you down. Guess what? If you're using Nagios or something like that, you might know before the site goes down. Something to consider.
Phase two. We're going to dig right into phase two. Very important topic. How do you keep your site running on an ongoing basis? The first thing is to maintain a development environment. I'm amazed at how many people don't actually do this. Running it properly means that it needs to be matched up to what the live site is currently doing. I like to ensure that they match up as much as possible, especially from a core software perspective. Make sure that you're running the same versions of the plugins on live and on dev. I like to do reverse syncs. I like to move content from the live site back to the dev site. I think it's just good practice to do that as often as you can.
When you have a dev site, that is where you should be running updates, which we're going to talk about in second. First thing is make sure you have this environment set up. Some of the manage providers, like WPEngine, actually sort of facilitate this. They do a pretty decent job of it. I'm more of an old school guy. I've been doing this for a while, so I kind of prefer to run my dev environment in a separate piece of infrastructure somewhere else. This is very important that either you're doing it or your agency is doing it for you.
Backups, super essential to do this. You should be backing up dev and live. Ideally, if something went wrong on your live site, I like to look to the dev environment first to pull files and restore. That's another reason why you really should keep that dev site maintained and up to date. In a catastrophic type of scenario, having a backup makes restoration much, much easier. I do recommend run your backups, dev and live, store them in another place. Actually, we stored backups for a lot of our clients in a physical box that's in our server room. It's off site from the server and it's also close to us here where we can go quickly, take those backups, kind of extract them, pull out one or two files if we need to. It works out really well for us. There's so many other ways that you can do it. You don't have to do it that way.
Updates and upgrades, major topic with WordPress. It's essential. This is not even debatable. You have to run updates and upgrades. There's two reasons why upgrades come out. Number one, security concerns. If something is out there and there's a vulnerability, the plugin, the theme, or the core is going to issue an update. The second reason is feature improvements, much like all sorts of other software. Now, it's kind of a catch 22. I like this graphic here, because it's like, "Aw." Sometimes to maintain a secure environment you have to go and accept changes to functionality that you may not want to. That's just sort of the way that it works with off the shelf software. There's no standing still. Sometimes you just sort of have to do what you have to do.
Surely people at this point want to ask about auto updates. Auto updates sound really good, but anything automated has downsides. We know this. I recommend disabling it. If you have advanced customization such that the update might run and just break a couple things, so if you have custom plugins, things like that, you really shouldn't have auto updates going. If you have professional guidance and someone that's helping you, like an agency or some sort of maintenance team, then let them run updates for you. If you're adverse to down time, don't run auto updates because I do regular ... blah blah blah, regularly see updates go and break software. If you're adverse to down time, don't do auto updates. if you have a basic theme, limited plugins that are reputable like we spoke about, and you really don't care if your site goes down at four in the morning, small business owners, a lot of times they can handle it til the morning til they wake up, then keep it enabled. Again, I'm focusing on the enterprise setting. I would disable it, much safer.
How to properly run an update. First thing, determine why it's updated. If it's a security reason, proceed quickly. Don't take your time. Again, this all depends on your risk profile. If you're running eCommerce, if you have user data, if your company runs solely online, those are important scenarios. In that case, proceed quickly. If it's a functionality update, you might be able to wait a little bit. A lot of this debates happening right now with WordPress 5. A lot of people are not too excited about the new editor, so they're holding off on 5 while security updates are still happening on version 4.9. Think about that. Maybe it can wait.
Before you do any update, whether it be theme, plugin, core, check for dependencies. One plugin that you update might break another. This happens a lot. I have one customer site that runs a series of plugins from the same company. It's a core plugin and then little plugins underneath to extend the functionality. That is a dependency nightmare every time we have to update it. Research dependencies. Then, it might be hard to research dependencies and really understand what you're getting into until you actually do it. Good time to use your dev environment. What can I say? Run it on dev. If it works, then go to live. Repeat the process. If a dev update fails, you can easily restore from live. You should be doing those reverse syncs anyway. There's no reason not to do that. This is the way that you should properly update, assuming that you're not doing the auto updates, which, again, I would not recommend.
The next thing in an ongoing basis that you have to think about is emergency response and how to escalate issues. Let's say that your sites going down at 2:00 AM in the morning. What are the steps that you're going to take to restore? Monitoring is only effective if you have a plan in place for when something bad happens. Document the process. Write down what you're going to be doing, step one, two, three, four. If it goes down, who responds? In what amount of time? What's the SLA that you have, whether with an internal group or with somebody that you're paying for this service? Is that person who's going to respond, are they permissed? Are they given the permission to contact the host on your behalf? That's something where you'd be surprised how often site goes down, we go to reach out to somebody, "You can't. We don't have permission to do it." That's actually problematic. What decisions are they authorized to make? Are they authorized to say, "Hey. We need to upgrade the server." Are they authorized to say, "I need to restore the backup." You sort of have to preplan. What can they do?
Then, finally, who do they notify? It goes down at 2:00 AM in the morning. They've made a certain amount of decisions and they're still having issues getting the site back. Who do they call next? Sounds like a no-brainer, but without a documented process, who knows? Very important on an ongoing basis and most of you that signed up are marketers, which is great. You know that you're never quite finished, so continuous improvement is very important. You know you need some level of partnership of planning to utilize this text stack and make constant improvements. Everything that I've spoken about before should make it easier to enable you to make these continuous improvements, the dev environment for example, super important. Make those changes on dev and push to live. I guess the reason that I have this here, you should plan for continuous improvement. You should budget for it. Again, the foundation for successful continuous improvement is taking care of those things we spoke about before. I definitely wanted to mention that. I'm trying to talk as quickly as possible 'cause there was so much to cover.
One other thing, on an ongoing basis, compliance monitoring. People think about this mostly during a deployment and then they just let it go. ADA is notorious. Everybody wants to be ADA compatible. There's those demand letters going out. When you build your site and you make it ADA compliant, that's great, but a lot of the compliance is around content. If you're not continuously putting up content the right way and checking, you could quickly become non-compliant again. This applies to all sorts of things, HIPPA, there's a lot of ongoing concerns there as well. PCI compliance for eCommerce. You have to continuously focus on the fact that, "Hey. I need this ... these levels of compliance. These are the steps I need to take." Have regular sweeps to make sure you're maintaining it. It's super important to do so.
I have a couple of pre-submitted questions. That summarizes the two phases. Again, pre-deployment, deployment, and then continuous work and improvements. These are the three questions that I really liked and as you guys signed up, remember, you got the auto responder. That says, "Hey. What do you want me to focus on?" A couple of you did reply. First one, "Thoughts on WordPress 5? If there's backwards compatibility for a while, should I upgrade?" Great question. There is backwards security compatibility for a little while. You don't need to upgrade right away. At this point, we've already been upgrading quite a few people. It's been relatively smooth.
The big difference on 5, and I'm sure you know this, is the new editor. It's called Gutenberg. Gutenberg, Gutenberg. You don't have to use it. You can install the classic editor and continue the way that you were. There will be a point in like a year and half or two year where the classic editor will go away, but you do not ... you're not forced to do it now. Generally, I think it's safe to do the upgrade. I would recommend doing it. If you're not comfortable with the editor, just stick with classic.
"When we redesign our site, should we re-theme or start from scratch?" That's an amazing question, very happy that the person sent that in. It kind of depends on the circumstance and how the first one was written, but more often than not, I lean towards a clean install. It's just sort of like the way that you clear technical debt is to just start over. I would probably lean in that direction, but every case is a little bit different.
Finally, "I thought you guys hate WordPress?" You know, it's not that I hate WordPress. I know I've had a lot of strong language about WordPress, been a chunk of my business, a big part of our business for a very long time, so I definitely don't hate it. What I hate is when people assume it does everything and it fits 100% of use cases. It never will. My [inaudible 00:30:18] toward projects is gather requirements, make a technical recommendation. Sometimes WordPress is that recommendation. Sometimes it's a custom CMS. Sometimes it might be AEM or SiteCore. I don't like the guys that just say, "WordPress can do everything," 'cause it can't. If you have sophisticated requirements, a custom build might be the way to go. If you have high quantity of eCommerce and have hyper secure environment, WordPress isn't the way to go. Yet, every project where I'm bidding against another agency, there's always, inevitably, the one person who's trying to make WordPress do everything and extend it beyond its comfort level. That's something to ... you have to watch out for.
With that, I do have some additional resources that you should take a look at. We have a blog. We have other webinars. We have videos. We have a bunch of E-books. We're going to be taking the content of this webinar and converting it into an E-book as well. This will be documented. I'm almost done with it. It takes a little bit of time. With that, again, if you ever need to find us, this is our location. We're in Northern New Jersey. Yeah. That wraps up the presentation here. I do have a little outro, though. Watch this quick clip. If you have any other questions, submit it to me. You know how to reach me.
Thanks so much joining me today. I hope you found the webinar insightful, hope you learned a couple of things. Before I let you go, I do have to mention, I just gotta do it, we have a new service offering this year. We're going to be providing managed WordPress services, which is basically oversight. We'll be doing security scans, for example, up to every hour. We're going to be doing 24/7, 365 up time monitoring with a 15 minute response guarantee. Basically, again, the idea is we're going to babysit your site so you don't have to. It's a great insurance policy. It's a price that [inaudible 00:32:17] doesn't even ... they'll laugh to approve it at only $295 per month, which is the starting level. If you want some more information about it, go to WordPress.npgroup.net. If you have any questions about anything we've covered in the webinar today, reach out to me directly. My email is going to be right here. Thanks so much and I hope to see you at the next webinar soon. Take care.