Websites are commonly evaluated based on performance and speed metrics. However, for business stakeholders, the crucial performance indicators revolve around conversions, such as sales or lead generation. Enhancing these metrics through various optimizations can significantly boost business growth and audience engagement.

Beyond these metrics, there’s an often-overlooked factor that stakeholders quietly monitor: cost. This encompasses the expenses associated with launching and maintaining their websites. In this article, we’ll explore how Pantheon Edge add-on services, particularly Advanced Global CDN (or AGCDN), assist teams and projects in saving both time and money.

Saving Time Saves Money

When launching or relaunching a website, teams typically prioritize the project’s completion. This intense focus encompasses various elements, including design implementation, content production, migration, and numerous technical pre-flights. However, technology isn’t the primary challenge. Meeting target dates often hinges more on human availability than the intricacies of website operation. AGCDN can expedite a project’s timeline, enabling faster site launches, especially when addressing legacy content, performance, or security issues.

While teams might not prioritize cost optimization during a website’s pre-launch phase, making simple decisions early on can lead to cost savings. By addressing potential post-launch efforts early in the project, teams can bypass some engineering tasks that solutions like AGCDN inherently offer. Notable examples include:

1. Domain Masking: It integrates various website parts, or even multiple websites and subdomains, into a cohesive experience. This allows legacy sections of a site to persist until they’re replaced.
2. Third-Party Cloud Storage Systems (GCS, S3, etc.): These can be routed and cached via Pantheon’s standard Global CDN. This is more efficient than directly serving images from those services, which can lead to increased costs.
3. WAF and Rate Limiting: These protections ensure site security from day one.

So, how do the aforementioned examples contribute to time or cost savings? When launching a brand-new site, many teams often inherit legacy content. This means they might have to continue serving certain legacy elements indefinitely. When marketing and development teams convene to discuss such projects, a relaunch timeline can span several months or even a year. This is the norm unless teams harness the full breadth of Pantheon’s features designed to enhance team and project momentum with WebOps.

To illustrate, teams assessing a legacy content archive often face daunting tasks like content migration. Alternatively, they might split the user experience by relegating legacy content to a subdomain. While this might occasionally mirror the new site design, it’s usually an afterthought in the project. However, there’s a better approach. By adopting a comprehensive strategy with Pantheon’s WebOps products and capabilities, teams can redefine their traditional project estimation and design paradigms for website relaunches, ultimately turning them into positive experiences.

Optimizing Costs and Efficiency After Launch

When managing the intricate ecosystem of a website, every service and component that affects the user experience has a corresponding cost. Often, seemingly benign elements, such as legacy content or image assets, can have an unforeseen impact on costs. While these costs shouldn’t dominate our focus, they’re vital to consider. For instance, when teams utilize cloud storage systems for their assets and then employ those systems for content delivery, they’re essentially doubling their expenses with ingress and egress charges.

It’s typical for platforms like Google Cloud Storage or AWS’s S3 to monitor asset access, presenting a variable bill at the end of the month. This ties into a universal truth about web performance: cached content is paramount. Not only does it rapidly deliver to users, but it also mitigates backend resource costs since the content, once processed, is reused multiple times.

So, how can we balance speed and performance, typical of edge caching, with the necessary inclusion of an external cloud storage system? We want efficient content delivery without straining the budget. Enter Pantheon’s Advanced Global CDN, an ensemble of edge customization capabilities. By merging these technologies, we can craft architectural designs that meet user and business growth needs, all while remaining budget-conscious.

Consider a client scenario: a website rich in high-resolution images hosted on an external cloud storage system, in this instance, S3. Their monthly charges weren’t for storage but for web requests for those images. With costs in the hundreds and the potential for these to skyrocket if content gains traction, a solution was vital. Pantheon’s approach? Utilize the built-in Global CDN that caches website assets and content and employ the Advanced Global CDN to proxy the external cloud storage, thereby allowing for tailored request-response-header manipulations. The objective? Seamlessly integrate the external cloud storage with the CMS on Pantheon, leveraging the Global CDN for efficient content delivery without breaking the bank.

Pantheon’s estimates revealed that even in a worst-case scenario, where all cached content was purged, repopulating the cache would cost around $40—a fraction of the client’s regular monthly expenditure.

The client’s elation wasn’t just due to the potential cost savings but also the newfound freedom to drive more traffic to their site without the burden of prohibitive egress fees.

Such innovative solutions not only foster trust between vendors and clients but also propel clients into a proactive mindset. They can visualize growth, harnessing Pantheon’s modern features and services. Ultimately, clients become more inclined to lean on Pantheon not just for solutions but for guidance on growth strategies, from expanding their data sources to personalization tactics.

About Pantheon

Pantheon is an innovative SaaS platform designed to empower users to create exceptional WordPress sites effortlessly. Offering a comprehensive suite of services within a single secure dashboard, Pantheon merges website operations seamlessly, spanning construction, hosting, maintenance, deployment, and security. With an emphasis on streamlined workflows, scalable infrastructure, and a lightning-fast content delivery network, Pantheon goes beyond mere functionality by fostering an environment conducive to extraordinary digital work. Additionally, Pantheon’s commitment extends to supporting users with education, professional development, and a dedicated focus on enabling teams to produce work the company can be extravagantly proud of.

The post Accelerate WordPress Website Launches and Cut Costs with Pantheon’s Advanced Global CDN appeared first on WebDevStudios.

Today, we’re diving into the fascinating world of WordPress multisite networks and how managed hosting can be the perfect companion to support this powerful platform. Whether you’re an industry professional or a curious reader, we’ve got you covered with insights, tips, and tricks to take your WordPress multisite network to the next level.

First off… What even is a WordPress Multisite Network?

Simply put, a WordPress multisite network is a feature that allows you to manage multiple WordPress websites from a single installation. Think of it like having your own virtual empire of websites, all conveniently managed from a centralized dashboard. This feature is particularly useful for organizations, agencies, or anyone managing multiple websites with shared resources and users.

Key Characteristics and Benefits

Simplified Administration

With a multisite network, you can effortlessly manage multiple websites from a single dashboard. From updating plugins and themes to managing user roles and permissions, having a centralized control panel allows you to streamline administrative tasks and save valuable time.

Shared Resources and Centralized User Management

One of the standout benefits of multisite networks is the ability to share resources among all the sites. This means you can have a common theme or plugin repository, minimizing redundancy and making updates much more efficient. It also allows for centralized user management, enabling seamless user access within the network. You can assign users to specific websites or give them access to the entire network, ensuring consistent user experiences and streamlined administration.

Scalability and Flexibility

As your online empire expands, a multisite network provides the scalability and flexibility you need. You can easily add new websites to the network, offering a consistent user experience while maintaining a consistent branding strategy across all websites within the network. You can easily apply global settings, such as logos, colors, and fonts, to ensure a cohesive brand identity. Plus, updates and maintenance become a breeze, as changes are applied across the entire network with just a few clicks.

Best Tips and Tricks for WordPress Multisite Networks

Carefully Plan Your Network Structure

Before diving headfirst into your multisite adventure, take time to plan your network structure. Consider factors such as website categories, user roles, and resource allocation. A well-thought-out structure will make managing and scaling your network much smoother.

Choose the Right Plugins

Selecting the right plugins is crucial for the success of your multisite network. Look for plugins specifically designed to enhance multisite functionality, such as those that enable network-wide analytics, user management, or website cloning, and always ensure the plugins you choose are compatible with the latest version of WordPress.

Regularly Update and Maintain Your Network

Just like any other WordPress installation, regular updates and maintenance are key to ensuring top-notch performance for your multisite network. Stay on top of plugin and theme updates, perform regular backups, and monitor for any security vulnerabilities. This will help you avoid any technical hiccups and keep your network running smoothly.

Choose the Right Managed Host for Your Multisite Network

When it comes to hosting your multisite network, not all hosts are created equal. Here are a few key things to look out for when selecting your host:

Scalability and Performance

Ensure your hosting provider offers the scalability and performance needed to handle multiple websites within a single network. Look for hosts that provide ample resources, such as storage and bandwidth, to accommodate the creation and growth of your network.
Finding a host with a strong uptime guarantee ensures that your websites are accessible to visitors at all times.

Backup and Security

Running a WordPress multisite network in a secure environment is essential, and you should choose a host that prioritizes the security and integrity of your network. Seek hosts that offer regular backups, robust security measures, and proactive monitoring to protect your network from potential threats.

Expert Support and WordPress Knowledge

Having a reliable support team that understands the intricacies of WordPress Multisite Networks is invaluable. Look for managed hosts that provide 24/7 support, with knowledgeable WordPress experts who can assist you with any network-related queries or technical issues.

Final Thoughts

You’re now equipped with some extra knowledge about multisite networks and the immense flexibility they offer. Make sure to plan your network structure, choose the right plugins, and select a managed host that can support your multisite network’s unique needs. Remember, choosing a managed WordPress hosting provider can be a game-changer for your network’s success. Now off to your WordPress multisite adventure!

About Pagely

Pagely helps big brands scale WordPress. As the world’s number-one managed WordPress hosting platform, Pagely was the first managed platform for hosting WordPress sites. With over a decade of experience scaling WordPress for the world’s biggest brands, Pagely’s tierless support (every support agent is a bonafide engineer), managed DevOps, and flexible tech stacks are unparalleled.

The post How Managed Hosting Can Support a WordPress Multisite Network appeared first on WebDevStudios.

If we’re still using SFTP for transfers to some hosts, it’s likely you may be too. But you may have also heard of rsync. Let’s all sync up and go on this journey together.

FTP: It works

Combined, WebDevStudios (WDS) and Maintainn have several customers which use a wide variety of hosts. SFTP works on all hosts, so it’s easy to go with that. But having used rsync for deploys on projects over 15 years ago, I understand the benefits. Eventually, the time came to see if we can adopt using it for future clients and projects.

WDS likes WPEngine. Why not use their git push functionality? As much as I like WPEngine’s git push (it’s fantastic!), we need something that is adaptable across all of our clients.

Does my host have rsync? How does it work?

If your host supports SSH, it supports rsync.

WPEngine added SSH support in 2018, so it was just a matter of time before we switched to rsync deploys for all of our hosts. Here’s how it works:

1. rsync establishes a connection to the remote host (usually via SSH) and runs another rsync receiver process at the destination.
2. The sender and receiver processes compare what files have changed.
3. What has changed gets updated on the remote host.

Only transferring what has changed makes rsync deploys an order of magnitude faster than traditional SFTP deploys where everything is uploaded. rsync also has the ability to compress files during transfer, making it even more efficient.

Configuration

We use a continuous integration service called Buddy for our deploys. It’s awesome because the interface is super easy to use and set up, but you can use rsync with anything from Jenkins to just running the shell command on your computer to upload files. rsync requires the following arguments, but it supports many options and can grow to be quite complex:

rsync [options] src dest

We typically run rsync as:

rsync -avz --delete /path/to/local/directory/ user@host:/path/to/remote/folder/

Before getting into the options, it’s worth noting that rsync is picky about the trailing slash on the source folder. If you omit it from the src folder in the above example, rsync will make a folder called directory inside /path/to/remote/folder/. That might not be what you want. I just always add trailing slashes to both the source and destination folder paths.

The options we’re using are:

• -a Archive mode (a good combination of options to start with if you’re not an rsync master)
• -v Verbose (shows files as they’re being transferred)
• -z Zip (compress files during transfer)
• --delete Delete (delete extraneous files at the destination)

Deleting files on the destination is where you’ll want to exercise caution. It’s a necessary evil for us because if a plugin or theme file gets renamed, we want the old file to go away. To control what gets deleted and what doesn’t, we’ll use an exclude list.

Excludes

Excludes control both what will get transferred from the source, as well as what shouldn’t be messed with at the destination. When you use it in concert with --delete, you’re making sure you don’t nuke something on the server that you want to keep.

There are probably some assets that you don’t need to transfer to your host. Skipping your .git folder with your project’s revision history database will save a bunch of time. You also probably don’t want to upload any node_modules folders, but you do want to upload the vendor folders.

You for sure don’t want rsync to delete your uploads folder; that would be bad. Add an --exclude option for each thing you want to exclude. Your rsync command will start looking like:

rsync -avz --delete 
  --exclude=.git*  
  --exclude=node_modules/ 
  --exclude=/wp-content/uploads/ 
  /path/to/local/wordpress/ user@host:/path/to/remote/wordpress/

The command is starting to get long and there are probably more things you want to exclude like wp-content/upgrade, WPEngine’s mu-plugin suite, etc. Alternatively you can put your excludes in a file (one pattern per line) and reference that instead:

vi rsync-exclude.txt

.git*
node_modules/
/wp-content/uploads/
/wp-content/upgrade/
/wp-content/debug.log
/wp-content/advanced-cache.php
/wp-content/object-cache.php

Then you can reference that file with the --exclude-from option:

rsync -avz --delete --exclude-from=rsync-exclude.txt /path/to/local/wordpress/ user@host:/path/to/remote/wordpress/

Keep in mind that exclude patterns beginning with a slash (/) are at the relative root of the sync folder, not the absolute root of the host. Also, the leading slash instructs rsync to exclude something in a specific location relative to the sync folder. By omitting the slash, rsync will exclude it everywhere.

For instance, the pattern .git* will exclude all .git files and folders (including .github, .gitignore, .gitattributes) throughout the project tree. The pattern /.git/ will just exclude the .git folder in the root of your project.

Extra work, but worth it

Using rsync instead of FTP does require a little extra brain power during setup than SFTP. Always test your setup on a staging site(!) where any mistakes won’t have catastrophic effects.

When using rsync, double-check your command at least 10 times.

—Aubrey Portwood, Senior Backend Engineer

As we refine working rsync setups, we apply those refinements to our deployment template so the next project to migrate to rsync deploys has the latest and greatest. Deploys go from minutes to seconds… well worth the effort!

The post Ditch FTP and Switch to rsync appeared first on WebDevStudios.

Please note: no one solution is perfect for every type of client. It’s why we have a few hosts in particular that we choose to work with depending on the project. But as a customer, you should know that you have options, too, whether your concerns are financial, performance, or purely based on up-time monitoring and support.

Support

One of the most critical things to consider is support for your website. The purpose of your website and its goals, whether it’s just for informational purposes or fuels your business, will affect how much support you need. For example, available support hours and type of support offered will vary from host to host and could even vary plan to plan. So, if your business is purely digital and your team is distributed across the nation or even the globe, then ensuring you have access to human support 24/7 is probably critical. You don’t want to be left out in the cold when trying to get a hold of someone at 3 a.m. should your site go down.

Alternatively, maybe hours of support isn’t your concern, but rather how you communicate. Some hosts offer chat support, while others offer a ticket-based service, which operates a little bit slower, like emailing back and forth. There may even be options for phone support, but that varies from host to host. If those are things that are important to you, you should find a host that will support you in the way that you need it the most.

SLA

In the same vein as support, a service level agreement (SLA), is going to indicate what type of guarantee you receive from your host to stay online. Often times, it fluctuates from host to host; so you need to ensure that your SLA covers what is most important to you. Be mindful of whether or not the SLA covers network availability, is an infrastructure guarantee, or if it’s on the hardware. It’s possible that the SLA could cover all, or just some of those. But again, it’s important for you to know what type of SLA your host operates under, so you know what is and isn’t covered by the agreement.

Technology

Most often than not, your hosting provider is purchasing their technology (aka infrastructure) from someone else. In the case of purchasing hosting directly from Rackspace or Amazon Web Services, for example, you’re purchasing directly from the source. However, most managed hosting companies are just reselling infrastructure with their own tools and optimizations built on top of it. This is totally acceptable. That’s the trade-off when you go direct to the infrastructure; you don’t generally get as many tools or platform-specific (WordPress) support. But certain technologies provide certain features that will vary depending on the type of service you need.

Let’s say that you need highly scalable architecture, ensuring that the technology behind your host (aside from SLA, customer support, etc.) is able to sustain the amount of traffic and load that your site requires from their technology. Most hosts these days disclose who their technology provider is, but if they don’t, it doesn’t hurt to ask. From there, you can better identify what type of infrastructure will be powering your site.

Performance

This goes hand-in-hand with the technology but also includes the unique optimizations that your host might build on top of that tech infrastructure. For example, a lot of the hosts that we partner with have their own mix for performance and optimization, which is why they’ve become so successful as brands.

It’s no secret that SEO is important for your site to succeed, and the easier it is for someone to get to your site and get the information they need, whether it’s a human or a bot, is going to net you better rankings. Fast sites historically perform better. So if having a good user experience and ranking higher on Google is a concern for you, then looking into the performance of the host is going to be of major importance.

There are also statistics that prove that the longer it takes for your site to load, the more likely someone is going to abandon your site and get their information elsewhere. And with hundreds of thousands of sites sharing similar content, we’re conditioned to getting information as quickly as possible. If you want to keep readers and visitors on your site, looking for a highly performant host is critical.

Backup

Backups are pretty standard these days, but be mindful of how long those backups exist and how easy it is for you to access them. Just because your host is taking a backup doesn’t mean it will be helpful for you if you need to implement it, which plays into the support angle. When you need to retrieve a backup, it’s usually at a critical point. It’s one thing to know you have a backup, but another thing to actually restore a backup.

Backups come in handy for a number of cases—just keeping a running copy of your site if you have to revert for any reason, especially when WordPress and plugin updates are released. Some hosts even remind you to perform a backup before every update you make to your site. Imagine drafting a bunch of blog posts only to find that a WordPress update broke your site! If you hadn’t made a backup, you would have lost all of those draft blog posts. Backups are there to do just that: backup your site and act as a safety net. So finding a host whose backup policy works for you, or even just being more mindful of what type of backup support you need, can set you up for success.

Dev Tools

Depending on what type of site you’re operating, you may or may not care about developer tools. But if you have a team of devs, or even a singular developer, the tools that a hosting provider offers can make a difference.

Staging sites, analytic tools to help you understand how your site and content are performing, or even things like more complex things like GIT integration can affect development workflow. Some hosts can be pretty restrictive with code reviews or force you to use their workflow. We try to recommend hosts that we’ve had great experiences with ourselves, so we’re not throwing you into the deep end with anything unverified.

Control Panel

One of the most underrated but simplest things to keep in mind is the control panel. Again, its importance depends on how much time you plan to actually spend on your site, but the experience could be dramatically different if you have only one website versus managing 10. How easy is it to get support, to the resources that you need, to access the tools, or even have the visibility over the performance of your accounts?

Having a control panel is like having the best navigation system for your car. A basic one will get you from point A to point B, but a souped-up one is going to give you more insight, more knowledge, and more tools to do more with your site.

To reiterate, there are a lot of variables to consider, which means that no one host is a perfect for no one client. Thankfully, our team works with the best of the best to provide you a great recommendation based on your needs. Consider what we outlined, think about your unique site needs and whether or not your current hosting solution is supporting you in the way in which you prefer to be supported. If it isn’t, our team is always happy to help talk you through options and point you in the right direction. Contact us today.

The post Things to Consider When Searching for a Website Host appeared first on WebDevStudios.

Awhile back, a long while, I started to get into hosting, this is when I first thought, “Everyone has a website, so I need one!” Not the right mentality, mind you, but that was then! It wasn’t too soon until I started to shy away from shared hosting plans into an un-managed dedicated server environment.

Fast forward about to about three years ago, when I started to get into dedicated servers quite heavily. This is when I began to host gaming servers for friends, and boy, let me tell you, it was a learning experience. Before I continue, let me say that I am by no means an expert on this subject, but I like to think I have more knowledge than the Average Joe when it comes to dedicated servers. So please, take this article with a grain of salt, and by all means, give me some feedback on what you would do, and why.

If you’ve ever hosted a popular gaming server (or website), you have more than likely experienced things like DDoS attacks, general web-based attacks, brute-forcing, etc… Granted, DDoS attacks are harder to pin down and usually boil down to your network speed and overall hardware, I found myself searching the web with, “Am I under a DDoS attack?” quite frequently. Keep in mind, I’m speaking from a single-server, non-load balanced system.

I’ve become an avid fan of CentOS. I know you probably have your own preferred OS, but they’re generally the same (I may be shunned for saying that), at least in their purpose. I can respect the disagreements this may pose, but remember, we’re all different. Anyhow, back on topic! It wasn’t long until I ditched the GUI’s like Plesk or CPanel in favor of my own know-how via command line. To this day I refuse to use any control panel if I can help it, I’m just faster typing than I am with clicking.

Dealing with Brutes

I found myself needing to deal with those pesky WordPress brutes that just won’t quit. There are a couple of ways you can do this, but I chose the easiest way, which was using WP Fail2Ban, Fail2Ban and ModSecurity.

ModSecurity: ModSec for short! It worked right out of the box, and honestly, I couldn’t ask for more. I’d seen this was in use on a client’s server awhile back, before I even started with WebDev, and have used it every since then. It works wonders for dealing with XMLRPC attacks and in studying these attacks; most of them don’t even include an XML body, and if that happens, ModSecurity just drops them immediately.

I heard about Fail2Ban a while back when I was playing a game with some friends. The first priority I had with Fail2Ban was to stop the flood of SSH attempts to my server, so I set it up to auto-ban users who attempted (and failed) to login via SSH and set a generous ban time of six hours and a max retry of three. This is why I love Fail2Ban: I can set the amount of times a user should be able to retry an action, and ban them for whatever time I set.

Fail2Ban wasn’t so straight forward to install. There is a little bit of configuration involved, so whip out your favorite text editor and start typing! Make sure you read through the jail.conf file and get a full understanding on how it works because that’s a whole other topic! On top of all that, make a copy of jail.conf and call it jail.local–edit the local file only!!!

Second priority was to handle FTP brutes, which was pretty simple since I’m using vsftp. I just enabled the directive in my jail.local. I mean, the configuration was already there–I just set it to enabled, and again, set a generous six hour ban time.

Last but not least, was WordPress. I really didn’t want a huge overhead on the site for banning people, extra database info, etc.. Since I was using Fail2Ban already, the use of WP Fail2Ban was a no-brainer. With this, I wanted to a bit more strict on the retry amounts, but more relaxed on ban times since I didn’t want to auto-ban myself for six hours should I forget a password. On top of that, I wanted to know when someone was trying to hit my WordPress installation. If I get more than one report/email from a specific IP address, I ban them permanently (more on that later). So here’s a snippet of my jail.local in case you need to use it:

[WordpressLogins]
enabled = true
filter = wordpress
#action = iptables-multiport[name=NoAuthFailures, port="http,https"]
action = %(action_mwl)s
logpath = /var/log/messages
bantime = 900
maxretry = 2

Notice in the config I’m setting the action. This action I’ve set will email me when an IP is banned with their IP address, whois information, and how many attempts they made. This way, I check my email every day, if I see an IP address that looks familiar, or has the exact same octets, and I just ban them permanently. Since this is a personal site, I usually look to see if they’re in the same CIDR range, if so, I consider that entire network hostile, and ban the entire range. If you don’t know what CIDR is, check this post out on Digital Ocean titled, “Understanding IP Addresses, Subnets, and CIDR Notation for Networking.”

When to Permanently Ban

This is really a case-by-case basis, and I realize that one site may get more hits than another, so take this information as needed. Also note that simply banning an IP address, or even an IP range, will not permanently stop these threats–though most of the time they just give up if you have an auto-ban system in place, which is why I love Fail2Ban. It does not stop them from just bouncing across a VPN or proxy and trying again. It’s up to you to be proactive in reporting these cases to the ISP’s listed in the whois database–even if you get no response, it cannot hurt. I prefer to selectively email ISPs and server hosts of potential abuses, but if you want to auto-send emails to parties listed in the abuse contacts, again Fail2Ban can do this for you. Here is a quick how-to on Stack Overflow.

When I perma-ban an IP from my server, I want to make 100% sure that it’s for a good reason, so I look for a pattern of IPs in my emails. If the same IP shows up more than once in my email, I consider that IP a threat, and just stop it from accessing the site. Of course, this could be at your own discretion, but if an IP has too many login attempts, I really don’t want that person hitting my site anymore.

Networks are more of a pain to track down. Usually I’ll get emails of attempt from an IP like 1.2.3.4, and a few more from another IP like 1.2.5.7, so I do a little research into those IPs. I use ip-lookup.net to see if multiple IPs fall within the same netrange. It’s super simple: Type in the IP and click the ‘IP owner info (whois)’.  Or, if you have whois installed on your server, just run a whois on the IP there.

My rule is that if an IP shows up with more than six to nine attempts, or if an entire network shows up an outrageous amount of times (usually thirty to forty), I either ban the IP or the entire network. Granted, there are other factors that come into play, such as country of origin, the page they were requesting, and more, but most of my bans are from other countries such as China, Russia, and Ukraine.

Here is a great reference on NixCraft that I constantly look at when I need to ban an IP; it’s one of those things I can’t always remember, so having a reference saved works well for me.

So that’s it. How do you guys deal with this? What do you think of this method? I would especially love to hear from you CSF guys since I’ve wanted to get into it, but have yet to do so!

The post Dealing with Brute Force Attacks by Yourself appeared first on WebDevStudios.

WP Engine is a WordPress-focused hosting company headquartered in Austin, Texas. WebDevStudios loves working with WP Engine and has a number of clients who are using their hosting services. We even host our own sites, including WebDevStudios.com on WP Engine!

Why do we love WP Engine so much? There are TONS of reasons!

• Easy to migrate your WordPress website to WP Engine.
• Easy to maintain whether you are a developer or an individual.
• Speed & Caching
• One-click staging with GIT integration
• Great customer support
• Dedication to the WordPress Community

WP Engine has a number of different plans to fit your WordPress website needs. Every plan includes amazing support that starts with website migration and continues through out the life of your website. As I have mentioned many times before, I am in no way a technical person, but with the help of WP Engine’s documentation and support team I was able to migrate my own WordPress website all by myself! They were also able to help me with a few small plugin issues post-migration in a very timely manner.

WP Engine is great to work with as a developer too! Brad has worked with the WP Engine team for a variety of projects from a simple blog to a complicated Multisite install. We can certainly say that due to unforeseen, random issues not every migration has gone super smoothly, but working with the WP Engine team is always a pleasure.

One of the biggest things we notice about sites that are migrated to WP Engine is the instant speed increase. If you are looking for a hosting company that is implementing all the best practices when it comes to site speed, this is it. WP Engine does a great job managing traffic spurts and site loading times. They also manage page-caching, database-caching and object-caching.and have a CDN upgrade to account for sites with a large amount of media.

As a WordPress development company one of our favorite features is the one click staging site. We really appreciate how WP Engine makes it easy to stage and test your site before pushing it live. WP Engine also provides Git integration available to all of their clients.  The Git-push-to-deploy setup adds the ability to deploy your applications using the open-source Git version control system. These features are great for us as a development company, but are also ideal for anyone who is looking to update a live site or learn WordPress development as they go.

We also can’t say enough great stuff about all the things WP Engine does beyond providing great hosting! WP Engine is a HUGE supporter of the WordPress community. They have been a sponsor for our local WordCamp Philly for the last three years and have sponsored a number of other WordCamps all over the country as well. They take their community role seriously and try to do their best to both promote their product and help WordPress improve the WordPress community.

If you haven’t already, check out WP Engine today. You won’t be sorry!

**DISCLAIMER: WebDevStudios is an affiliate member of WPEngine. The links in this post are affiliate links which means that if you make a purchase after clicking the links in our post, we get a small payment from WPEngine as a thanks for promoting their product and brand. WebDevStudios does not participate in affiliate programs of products that we do not love to use ourselves – – we fully endorse and regularly use the products we promote on our site. If you have questions, let us know!

The post Products We Love: WP Engine WordPress Hosting appeared first on WebDevStudios.

Rackspace is the second venture-backed technology company to go public this year. ArcSight had its public offering on Feb 14, 2008. 48 venture-backed tech companies went public in 2007, according to the National Venture Capital Association.

Rackspace was founded in 1998, and has been a leading website hosting provider ever since. WebDevStudios utilizes Rackspace servers to host all of our production websites.

The post Rackspace Hosting Goes Public appeared first on WebDevStudios.