Since this is the internet – and the rules of the internet clearly state everyone gets an opinion, I’d like to share one of mine around website hosting billing plans. Quick backstory: 10+ years ago when we launched Pagely we did so with a simple line on our pricing page denoting a rough estimate of the expected capabilities of that plan ie: Plan – 1 was suitable for ~1 million pageviews. Along came the next several providers who did something similar with one important difference. They actually attempted to measure and cap pageviews per hosting plan, bracketing their plans by this new billing metric. In my opinion Pageviews used as a billing item is a predatory and anti-consumer practice and you should be very wary of working with any company that applies this #successtax to your monthly bill. Definition of anti-consumer : not favorable to consumers: improperly favoring the interests of businesses over the interests of consumers Hi, I’m Joshua Strebel, Co-founder and CEO of Pagely – A leading Managed WordPress hosting company – Thank you for attending my TED Talk. What are you buying when you are buying “hosting”? To host a WordPress site you need a few key components. A server (a computer) connected to the internet with software installed to process requests and responses for your application. Storage / Disk space attached to that webserver to save your files to. Data Transfer / Bandwidth. This is the pipe the information flows through. That’s basically it. Hosting providers typically lease/sell you packaged fragments of these resources for a monthly fee. Plan A, Plan B, Plan C. etc. Of course there are other items that may be line-itemed such as included support levels, CDN GB’s per month, managed services, etc. Plan A has X amount of consumables for Z price. It’s all fairly straightforward as most consumers understand what a Gigabyte of Disk space is and can at least grasp that more CPU/RAM offered should equate to more potential performance. “Pageviews” does not fit this model well – as the definition of a pageview is amorphous and subject to exploitation. Oh, and spoiler alert, PHP workers is not a valid billing metric for WordPress hosts either. What does an automobile lease have to do with hosting plans? Pageview limits on hosting plans are akin to annual mileage limits on auto leases. It’s a cap on the use of an asset you already purchased. In an automobile lease context a mileage cap at least has some merit as being a form of controlling the depreciation of the vehicle – you are essentially financing the deprecation of the automobile asset with a lease – and the lease company expects to sell that car (New retail value – Depreciation) when you return it. If the depreciation is too high, they lose money on that transaction as they have to sell it for less than they calculated. Your hosting plan is not a depreciating asset though – the hosting company is going to sell the same resources to the next customer when you are done for the same or likely higher fee. Therefore in my humble opinion: Pageviews are just an arbitrary anti-consumer fee – a penalty tax for using the service you already paid for. A Pageview is (depending on who you ask) a wrapper around these items: A measurable amount of Data Transfer in and out A measurable amount of CPU resources to process the request and render the response A measurable amount of Disk and Database activity Are you not already paying for these items as part of your hosting plan? Hint: Yes you are. But wait, there’s more – and my colleague will dig into these more in a future post. This pageview billing model is so poorly defined by the hosts that use it – it is ripe for abuse. It’s a scheme to generate revenue for the hosting company and unfairly penalizes the consumer. Hint: You already “paid” for the sum of the parts of a “pageview”. No two pages are the same. A cached page even with a few images can be served a million times a month with ease, and yet a badly coded membership-site page may tax the hardware it runs on each time it loads. They have very different cost profiles to the host – yet both are treated equally under this model. If you invested the time to optimize your site, get it caching well and then blow it up with viral traffic.. That is a GOOD day for you and costs your host pennies of the monthly fee you are already paying them – yet when you get the overage bill for exceeding your pageview cap at the end of the month, are you going to enjoy that tax on your success? If you want to keep paying twice for the same resources you are welcome to. I simply do not think that is fair. Our friends down in Austin have made millions on charging their customers overage fees for exceeding their monthly pageview cap – even to the point having to publicly respond to criticism – only to keep the practice in place. Reminds me of airline baggage fees and fuel surcharges. and An “online payment convenience fee” when they only accept payments online. and JetPack being “free”. Happy WordPress’ing – Joshua Strebel
PHP workers are getting a bad rap lately in the WordPress hosting world. Most commonly, they’re being cited as a scapegoat for a hard upsell by the host. Let’s dig in a bit deeper and discover the truth behind PHP workers and how they apply to hosting WordPress sites. Table of Contents What is a PHP Worker? Why Would I Need to Care About PHP Workers? Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? How Many PHP Workers Do I Need? How to “Tune” PHP Workers Here’s the Real Question That You Should Be Asking Don’t Believe Us? Want Proof? There you are, just minding your own business – literally minding your online business – when your workflow is suddenly interrupted with a prolonged loading page. You say to yourself, “That’s weird. It seemed to be working fine just a moment ago”, so you tap the refresh button. After a moment, you see a white screen with a 50x error printed across the top. You want to be sure that it wasn’t just a freak accident, so you give that refresh button one last tap and the WordPress admin page you were working on loads right up. It’s like nothing ever happened. Since the incident, a million thoughts of panic and discomfort are running through your mind. “Was this just a random issue? Should I worry about this? How often does this happen? Do my customers see this too?” Unfortunately, there’s no magical catch-all answer. This “blip” or “timeout” could be attributed to any number of causes throughout your hosting stack. Within this article, we are focusing on the specific and casually offered, “you need more PHP workers” reframe that far too many WordPress hosting support desks seem to respond with. What is a PHP Worker? A single-core processor on a timeline. 2 PHP workers drop tasks into the processing queue and are handled in a fairly consistent fashion. Memory usage stays somewhat constant as CPU usage modulates with workloads. In a basic sense, a PHP worker is a background computing process that runs PHP code. It hangs out on the server, waits to be told what to do, does it (hopefully in a timely fashion), returns the response, then goes back to twiddling its thumbs until another task comes in. When they pick up a new task, they’ll use whatever CPU cycles and RAM they have available to get the job done. To ensure that they always have resources available for when the next job comes in, PHP workers also reserve some resources to stay warm after they finish. Of course, you wouldn’t want to have a bunch of PHP workers sitting around and eating up additional resources just to sit there idle. In addition to being statically defined by always keeping the same number of PHP workers ready, they can also be dynamic. By utilizing dynamic PHP worker counts, they’re able to grow or shrink as necessary. In a WordPress context, PHP workers are kind of dumb. Since WordPress runs as a single-threaded application, a single PHP worker handles the entirety of the request. Because of this, a typical WordPress request looks something like the following: A request comes into the web server and passes it off to PHP. A PHP worker within the worker pool starts processing the code. If your code requires information from the database, the PHP worker then passes a query over to the database server, then waits to get the results back. Once the worker receives what it needs from the database, it then performs further processing before finishing and passes the completed work back over to the webserver. Why Would I Need to Care About PHP Workers? Most of the time, you don’t need to know or even care about how many PHP workers your hosting account has, much less how they are allocated – until you run out. When high traffic to your site, poor performing code, or a combination of the two uses up all your available PHP workers, it bottlenecks the chain. Once you run out, requests get turned away or queued until one of your PHP workers finishes a task and can take on another one. Why Would My Site “Run Out of PHP Workers”? Wouldn’t More PHP Workers Fix the Problem? As we stated above, a PHP worker stays “blocked” while active. During that time, it’s not able to perform any additional tasks until the current task has finished. The benefit of having more PHP workers is that it may allow the site to handle more tasks simultaneously. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing. While handling more tasks simultaneously may help with making sure that every task gets finished, excessive PHP workers can also cause individual tasks to take longer. As each task takes longer to finish, this means that when resources are exhausted, it can take quite a while for spare PHP workers to become available. Typically, the number of PHP workers is not as critical as the type of workloads that those workers are performing An excellent way to think of your worker queue is like a list of tasks. If you have a few tasks that you can handle at once, you can get them all finished relatively quickly and become ready for more tasks. But if you take on too many tasks at once, you might find yourself overextended, take longer to complete each task, and see your backlog grow exponentially. Long/Slow Running Tasks Clog Up the PHP Worker Queue Code performance is the most significant factor in regards to PHP Worker capacity. Let’s take a look at a very simple instruction in PHP: print(“This is a PHP function”); This instruction alone occurs almost instantaneously. Because it happens so quickly, it consumes 1 worker for only a brief nanosecond. On the other extreme, let’s look at a complex instruction that could occur when a customer searches for a product on an eCommerce site. If the customer was searching for car parts that are compatible with a particular product, your code might handle it like this: Give me all products from my database that match the keyword “spare part”, has a price between $5 and $15, and is compatible with SKU “4232”. Now take these records and process them. For each one, get the paths for up to 3 corresponding image thumbnails. Before making the items available, make a call to my 3rd-party inventory management system API and check to see how many are available. Once you have all of the products and inventory counts, start building the web page with product reviews, social media posts, and the product images for each product. Print that content to the browser along with my header, footer, and sidebar. Relatively speaking, this process keeps 1 worker occupied for a very long time. Each task waits for its part of the instructions to finish before it can move on to the next. Combine this with that page builder plugin that you love so much to generate the 3MBs of HTML, and you’ll be left with a reasonably substantial PHP process to chew through. Now, if your database is slow for any reason, it’s going to take a few hundred milliseconds longer to return its data, keeping that PHP worker active while waiting. Let’s say that you’re hosting your product inventory management system at a different cloud provider – the PHP worker needs to wait for that API communication and transaction to take place. You get the idea. The worker has to finish a task before it can take on any more tasks. Most of the time, it’s a non-issue. It does its processing, your page renders in 300-600ms, and you move on with your life. 2 PHP workers drop tasks into the CPU timeline. They’re processed consistently at first, but then 1 task “waits” as the other worker tasks continue moving. This demonstrates how a worker can become occupied or “stuck” while the transaction takes place, unable to do anything else until the task completes. Juggling Too Many Tasks At Once On your typical WordPress site, the whole process works fine a million times a day. Except when it doesn’t. Let’s say that your marketing team just sent out a wildly successful newsletter blast. It drove an influx of traffic to your site, and the crew is popping champagne in the break room. But on your server, it’s a different story entirely. You’re getting the same types of requests, but they have now multiplied and are happening all at once. From there, your PHP workers get bottlenecked as they cannot clear their tasks fast enough. That’s when your site slows to a crawl. A Note on Request Queuing Most modern hosting stacks use PHP-FPM to manage the number of PHP workers, allowing tasks to queue up gracefully while waiting for CPU resources to become available. If you are running Apache and mod_php, request queuing won’t happen gracefully, and any new request is unceremoniously dumped. Queuing is an excellent solution to handling short bursts of traffic, but has a downside that becomes apparent when your sustained traffic occurs at a higher level than you can process. When every request spends time in the queue, all you are doing is adding additional time to the response. If the queue size is large enough, you can even get into a scenario where each request is waiting for greater than 30 seconds before work even starts. At this point, you aren’t completing any requests in a useful amount of time. You would have been better off serving errors to half of the traffic and content to the other, rather than make everyone wait half a minute or more. 4 Workers drop tasks into the CPU timeline, which are processed in a fairly consistent fashion at first, but then begin to queue up waiting for available CPU. In summary, the PHP-FPM request queue lets you use the optimal number of PHP workers while still handling traffic bursts. However, it still needs to be capped at a size that allows it to process the entire queue in a short amount of time. Otherwise, you could end up in a runaway delay situation. Exhaustion of Server Resources As we’ve previously mentioned, each PHP Worker consumes a bit of RAM and CPU cycles. Even if you have 50 PHP workers to handle your workloads, your run-of-the-mill WordPress hosting plan likely does not have enough resources allocated to run all of those workers efficiently. One cannot merely add more PHP workers in a vacuum. Increasing capacity to serve additional website requests means increasing CPU and RAM (server/container size) in proportion to the PHP workers, based on what your workloads demand. 4 Workers drop tasks into the CPU timeline. As the volume of tasks increases and all available memory is occupied, tasks are unceremoniously killed off to make room for the tasks coming in behind it. This is a demonstration of the Out of Memory (OOM) task killer which, when active, causes all sorts of unpredictable performance issues. The 4 variables of CPU, memory, PHP worker count, and workload (code efficiency) all need to be in harmony when it comes to right-sizing a hosting stack. It’s worth mentioning again that code efficiency is the most important. Increasing the other 3 may just let you do more of the slow and inefficient tasks (concurrency) with no effect on how fast those tasks complete (performance). Cache is King Caching, of course, helps alleviate many of the bottlenecks described above. Caching at the database layer with native MySQL query caches (going away in MySQL 8), leveraging the WP Transients API, and/or a Redis Object Cache, saves the PHP worker from having to communicate as often with the database and wait for a response. Caching further up the stack in the webserver prevents the PHP worker from even being asked to do anything. Unfortunately, it’s not always possible due to session cookies or dynamic requests. Caching responses from 3rd party APIs, like the inventory management system that we described earlier, reduces that “waiting” time as well. The more efficiently you can cache and still meet your business goals for the website, the less PHP work needs to be done, which means an overall smaller demand on server resources. Newer PHP Versions are Faster Than Older Versions There are several benchmarks you can view online, and they all say the same thing: PHP 5 is faster than 4, 7 is faster than 5, and 7.3 is faster yet again than 7.2. You get the idea. You may not have any control over what version of PHP your host provides, but if you do, always opt for the latest version. The speed (and security) gains of newer PHP versions are real and quantifiable. How Many PHP Workers Do I Need? There is no universal answer to this question as each WordPress site and workload is different. Generally speaking, you want to tune the number of PHP workers to consistently use 80-100% of your available CPU capacity. Complex workloads may only allow for 2 PHP workers before consuming all available CPU. In contrast, efficient and optimized workloads may allow for 4, 6, or 8 workers per core with identical server specs. Too many workers for the available CPU simply makes everything slow down as they get queued up, and the CPU spends much of its time switching between tasks, rather than getting work done. Too few PHP workers for the available CPU wastes resources, since some percentage of your CPU remains idle, rather than getting work done. A good optimization of workers to CPU cores. 4 PHP workers leverage 2 CPU cores and have ample memory to process each task efficiently with a little (but not too much) buffer before maxing out. How to “Tune” PHP Workers Tuning PHP workers is a fairly straightforward process as long as you follow a few basic rules: You want to run as few workers as possible. You should have a hard limit on the number of PHP workers based on the memory used by each worker, and the amount of RAM on your server – this is very site-specific, as each website may have a different usage profile. Once your CPU is at 100% utilization, adding more workers simply makes each task slower. If your worker CPU usage is low, but your requests are still slow, your bottleneck is in something PHP is making a request to (Database/Cache/API). Increasing the number of simultaneous requests to that component might make it slower, so you have to monitor it. An excellent question to consider is this: why are you trying to tune your PHP workers? Is it maximum concurrency or maximum performance? At Pagely, we always try to understand the customer’s business goals when recommending which “hosting plan” to use. From there, Pagely tunes each plan to the specific customer’s needs. Dozens of small sites have a very different workload footprint than 1 large site on the same spec hardware. Tuning PHP Workers for Many Low Traffic Sites on the Same Server With lots of sites, you have two main worries: memory overhead and noisy neighbors (this can include just your own sites on the same VPS). Memory overhead is mostly static, based on the average memory usage of each site. For simple brochure-style sites, you might plan for 128-256MB of RAM for each site (plus some fixed OS overhead, depending on your stack). At your average cloud provider, you are going to be looking at instances with a higher memory-to-core-count ratio on the smallest size. As you scale, you’ll then switch to a lower memory-to-core-count ratio. As for PHP workers, you are going to want to use dynamic worker limits, generally with a minimum of 1 PHP worker to reduce latency and setting a maximum that only uses 25% or 50% of the server CPU. Setting these parameters lets a couple of sites burst at simultaneously, without causing performance issues on the other sites. Each site gets access to the CPU, but no one site can consume all of it at once. Setups like this tend to have a ton of unpredictability, so you are better off focusing on stability in worst-case scenarios instead of maximum performance and efficiency for any single site. Tuning PHP Workers for a Single High-Traffic Site With a single site, you can match the hardware and worker counts to get the most bang for your buck. You will almost always want to use cloud instances that are optimized for computing power (number and speed of CPU cores). From there, you should use either a fixed number of PHP workers or a dynamic configuration with a high minimum number of workers. If your database is running on another server, a good starting point is to take the number of CPU cores and multiply it by 2. Increase workers-to-CPU-cores when: You are making a lot of database or API queries. Your average response time is minimal (< 100ms). Decrease the workers-to-CPU-cores ratio when: Your codebase has low efficiency You aren’t making many database or API queries You are generating very large responses Just Throw More Hardware At It This is our least favorite solution – and one that we only recommend after we’ve gone through everything else. Sometimes it just has to work, right now, and refactoring poor performing code is time-consuming and not always feasible. Throwing hardware at the problem usually works, but with a major downside – it gets really expensive, really fast. You can typically increase concurrency and handle more tasks, but those tasks will never get any faster until the code efficiency is addressed. As our CTO says, “it just allows you to do more of the slow things”. Here’s the Real Question That You Should Be Asking We get it – several of the hosting companies have trained the consumer base to be concerned about the “number of PHP workers” and to think that number has some magical effect on how their WordPress site performs. We also understand that many of these same WordPress hosting companies have successfully brainwashed everyone to concern themselves with “number of Pageviews” as well. (Pageviews as a bogus billing metric is a topic for another blog post entirely.) These are both the wrong questions to ask when shopping for a scalable and reputable host for your WordPress website. The question you should be asking is simple: Does this host have the skill and knowledge to configure my plan specifically to my needs so that I can get the most bang for my buck (performance to value)? If they keep pushing plan upgrades and telling you that “you need more PHP workers” without any background analysis offered, you already have the answer you need. Don’t Believe Us? Want Proof? We’ve run a full analysis of the impact of PHP workers, including all of the source code for our tests. If you want to take a deeper dive into our data, a full write-up is available within our PHP worker benchmarking and analysis article. Happy WordPress’ing.
It’s the first day of April – 2020 Big Sigh Be stay safe out there, please.
Ten years ago this month, we launched Pagely and kicked off what has grown into the $2-3 Billion dollar channel known commonly as Managed WordPress Hosting. At the time, people questioned the need for the services they now take for granted, and which are increasingly becoming commoditized. Over the last decade, the wider WordPress ecosystem has clearly benefited from faster and more secure websites, better deployment workflows, and knowledgeable, WordPress-specific technical support. I’d wager to say the wider hosting market, in general, has also taken notice and adapted to serve a more discerning clientele that has come to expect more than Level 1 call center upsells when interacting with their host. It’s been an exciting and, at times, terrifying journey for Sally and I as we’ve put our efforts towards building a product and then building a company. We’ve become parents during this time and watched as our employees started or expanded their own families. We’ve seen competitors enter, grow, and dominate wide segments of the market. We’ve also stayed true to our simple philosophy of “business is personal” and have endeavored to interact with every employee and every customer with integrity and empathy. Thank you to all our customers past and present for joining us on this journey. As the Managed WordPress Hosting channel expanded, and the service offerings coalesced around similar feature sets and positioning, we remained laser-focused on moving up the value stack. Our approach was driven in dual parts by instinct and survival. For the type of company we wanted to be a part of, one that put our employees and customers first, we had to seek out and serve the top-tier customer base that would support and value that ethos. It’s not a stretch to say we, a revenue-funded company, were also being squeezed by the venture-funded companies with massive war chests and the overseas players that enjoyed lower expenses on labor. If a company does not adapt, it does not live. I would be remiss to not recognize WP Engine, SiteGround, Pantheon, GoDaddy, and the rest of the now saturated mid-market and B2C WordPress hosting field that have played a significant role in this channel Pagely created. They most definitely have done more than we ever could alone to expand and broaden the landscape… as they continue to bludgeon each other for mass-market supremacy. It’s near impossible to forecast what the next 10 years may bring. At Pagely, we are investing heavily into a new product we feel is the logical next iteration of managed application hosting, NorthStack. As technology changes at a quickened pace inline with the evolving tastes of consumers, we are exploring additional application ecosystems beyond WordPress such as Node.js, Laravel, and Gatsby, while leveraging and building the next generation hosting infrastructure to support it. Hi, I’m Joshua Strebel, CEO and Co-founder of Pagely, a 10yr old profitable “startup” and the innovator of Managed WordPress Hosting. Thank you for attending my TED Talk.
To wrap up this series on my WordCamp Phoenix keynote, I’ve once again embedded the video below. In this post I will unpack a couple of new concepts and ideas from that talk. Catch up here with part one and part two. Set the Employees Free In a typical corporate hierarchy most, if not all, key decisions are made at the top and handed down to teams below for execution. Those teams are then held accountable for the outcome. If the idea was sound, and the execution successful, the executives at the top take credit and the world keeps going. If the idea itself was a poor one, regardless of the quality of execution, the team that was told to execute will likely take the brunt of the blowback, and the CEO will get a golden parachute as the company falls into bankruptcy. I’m kidding, that almost never happens. Or in a different context, a lower level employee will be hamstrung and boxed into a tightly defined role with clear boundaries and permissions. They’ll be unable to adapt to edge cases or surprises, as the process they must follow is dictated by levels far above them. In my eyes, this is the wrong way to run a company if your goal is to build a vibrant, forward-thinking organization powered by intelligent and engaged people. What we have tried to do is give the authority to think and act to every member of our team, by trusting them to be the critical thinking and intelligent humans that we hired. As leadership and employees define the mission goals and take ownership of its execution together, multiple opportunities arise to sanity check ideas and revamp process before they are too far gone. Trust is the mechanism that makes this work. Leadership has to trust in the training and cultural indoctrination of their employees to make wise decisions. Similarly, employees have to trust leadership to not micromanage and second guess their work. At that point, the responsibility and accountability for outcomes can be fairly judged and assigned. For example, if your company screens for and hires competent support agents, then why not free them to help the customer thoroughly and effectively? Yes, this means you have to attract the caliber of talent you can feel comfortable with working off leash, be willing to pay them well, and be ok with the occasional learning mistake. The long term outcomes for the company and the customer will be more positive in the long run. A more skilled and capable team actually saves money in down the line and can drive additional revenue via increased customer satisfaction. I do, however, realize this does not work at every company. McDonald’s can’t let every employee get creative in how to prepare, package, and deliver fast food to the customer — but most knowledge economy companies can adopt a bottom-up approach, and be more successful than otherwise. This concept and others are found in the books below, which all share in common military themes in leadership, but each one also takes a critical look at the failings of top-down leadership and how it can be improved. Team of Teams Turn the Ship Around Extreme Ownership No Really, Set Them Free Everyone has the best intentions and an employee’s journey with a company will be a long and fruitful one for everyone involved. Of course, we know that is not always the case. Strategic shifts, morale, the likelihood of advancement opportunities, culture, relocations… the list goes on of reasons why employees and companies part ways or stick together. The situation that I think is the most dangerous is continuing the employment relationship with the employee that seems to waffle on the lines between mediocre and poor performance. In these cases we’ve always looked back and thought to ourselves we should have parted ways sooner. Hindsight is always that we did them and the company zero favors by delaying parting ways. In the larger context, we must consider the dozens of other families we are responsible for and put that greater good ahead of the discomfort of letting go a single worker. While I did not mention the above specifically in this keynote, It’s been a common theme in my talks as it seems to be a mistake we often repeat. Get the right people on the bus, and the wrong people off it. Take a look at my keynote in its entirety below, and please do follow up with thoughts and comments.
This is part two of a series on my recent keynote for WordCamp Phoenix, where I took the stage in front of my local business and WordPress community to share some insights and lessons learned. The video is embedded below and in this post, I will unpack a couple of the concepts and ideas from that talk. For more insight, see part one of the series. The Blue Ocean Strategy I read this book several years ago, and it was vital in shifting how I thought about our company and how we compete in the marketplace. I was also a particularly receptive audience to the primary lesson: differentiation. I have a screw loose somewhere that has always forced me to do things in a unique way or to make something mine. Not so much as reinventing every wheel, but for some reason, I could never just do things the same way as everyone else. The gist of the book is that to succeed and grow in business, you must move out of the competitive red water and into open blue ocean. Identify an opportunity to differentiate yourself from your competitors, draw those lines with messaging and branding, and then own the new open channel you created. When we launched Pagely in 2009 we had the market all to ourselves, a blue ocean. Within a few years, there were a dozen or so competitors all saying the same things. Many of them were massive companies moving into the space, or well funded VC backed companies hellbent on growth at all costs. In this very, very red ocean, we had to ask ourselves how we were going to survive as a revenue-funded small team. We elected to seek open water and over the course of a few years we re-positioned our brand, revamped our service, and began to target a different segment of the widening channel. We left the volume driven B2C segment to everyone else and focused on the needs of value-driven B2B, higher education, media, and enterprise companies with a flexible and high-touch approach. That kicked off a multiyear run of growth for our company and most likely saved us from sputtering out. Your company’s unique selling proposition should be defined by you, not by your competition who will happily paint you into a disadvantaged position if you let them. The compelling narrative of your story can aid your buyer in selecting your firm out of many. In a side-by-side comparison of solution providers in your space, what makes your firm stand out? During my keynote I described our journey to discover and sail to new blue oceans and cited how in my mind the new block editor in WordPress v5 is an example of this process. In order to stay relevant and continue the WordPress OSS dominance in the CMS space, it had to modernize a bit and seek a novel way to differentiate from a growing list of competitive platforms. There is disagreement within the community if the new block editor was the right thing to do, or was implemented correctly, but I believe something is better than nothing to keep WordPress relevant. As business owners, we always need to be thinking about the future, and a key question to answer is how we’ll stay competitive and prosperous. The last time we asked this question the answer we came up with was NorthStack, a new service we’ll be launching in the coming weeks. In the next part of this series, I’d like to look at how we empower our team to be successful. For now, please check out the video below and let me know your thoughts.
I had the pleasure of being a keynote speaker at WordCamp Phoenix this winter. I used the opportunity to share some hard-earned insights and lessons-learned from my 10 years as CEO of Pagely. The video is embedded below. In this post I’ll unpack a couple of the concepts and ideas from my talk. These are things every business leader, at every level of the company, should be aware of. They impact our perceptions and decision-making processes, even when we think we’re being objective and logical. Bias One of the topics I explored was Bias. Specifically how Authority, Attribution, and Survivorship bias may influence our experience working in business and participating in communities. I wove these topics into the presentation (though, I’m not sure how effectively). Authority Bias We tend to explicitly trust conference speakers, or anyone in some capacity of leadership or authority. We assume what they say is genuine and true, and we may not critically question their agenda. This is authority bias. Most thinking people have a pretty well-tuned BS detector when it comes to politicians and the media, but they may let their guard down in other areas. To illustrate this I used myself as the first example. I shared my thoughts on the market positioning of various players in the WordPress hosting space, and then acknowledged that those competitors may not see it the same way. Since I was on stage as an authority figure at that moment, the audience may have been influenced by my message. I closed this section by asking the audience where we may be failing to question the veracity of affiliate-driven hosting reviews and the decisions around the feature roadmap and future of the WordPress platform. Unchecked authority bias inside of organizations can lead to bad decision making and groupthink. Inside of Pagely, I expect our teams to ask the why questions of me and their team leads. Asking why a decision was made, or why it was made a certain way, is important for short-circuiting groupthink and averting wasted time and resources on pet projects or ideas. Attribution Bias The downside of asking the ‘why’ questions of someone and attempting to gain clarity on their agenda is that it is a great opportunity for attribution bias to creep in from the person being questioned. As human beings, it’s easy to wrongly attribute an aggressive or negative intention to the person asking the question. It’s also easy to fall into a defensive position and ignore the validity of questions we don’t like or, even worse, insult the character of the person asking. To illustrate this to the audience I asked some uncomfortable questions about the future of WordPress and whether its popularity has peaked and it may be declining. To support my questions, I cited some quotes from dissatisfied community members. Acknowledging that, in that moment, the audience may be considering the audacity of a speaker at their community event questioning the direction of that same community, I stated my intentions were good and asked the audience to consider how not asking these questions may impact their current and future livelihood. Sometimes it’s easier to just go along with what seems like a good thing, and not even consider the possibility of things taking a turn for the worse. Survivorship Bias I catch myself often saying something like “I did it, it’s not that hard” and every time I do that I am demonstrating my own survivorship bias. There were so many points in time where it could have gone bad, or worse, for Pagely. So many times when things could have not worked out. In those alternate timelines our company may have died early. Sometimes we don’t consider all the near misses we survived and take a meaningful lesson away from the experience — but usually we do. Survivorship bias may also play a roll in your company in that dreaded “that’s the way we have always done it,” meme everyone groans about. Be careful not to let a bad or outdated process continue just because it survived up to this point (which may be long past its usefulness). I touched on this point by sharing with the audience a bone-headed mistake I recently made. Ultimately we survived the mistake, of course, and I encouraged the audience to go out there and break stuff (an analogy for making mistakes while learning). I told them it won’t be fatal to them or their business. This is my own survivorship bias on full display. Being Your Own Best Cheerleader “Fake it ’til you make it” is an overused reframe commonly thrown around. I feel that phrase is disingenuous. You cannot fake the consequences of failure. They’re very real. However, to be an entrepreneur you have to be a bit self-delusional. Somehow you have to find the hope and conviction that things are going to work out okay. Finding that conviction can be very hard when faced with the long odds of success and the inevitable landmines along your journey. So, it helps to be your own best cheerleader, and find something to cheer about, even when there’s nothing worth cheering about. This can sometime lead to what the interwebs refers to as #hustleporn, or the celebration (and validation) of the 80-hour-a-week grind of the perpetual startup ‘bro’. Don’t be that person, but do celebrate your successes. Sometimes that success may just be mustering the energy to keep going. In a follow up post I’ll explore some of the other topics I covered in the presentation, like market positioning and blue oceans. Stay tuned for that, and in the meantime please watch the video below. I’d love to hear what you think.
Announcing NorthStack by Pagely Every now and then we get to do something really big and impactful — something that leaves an enduring mark by changing the way things are done in an industry. This is not an incremental update to a product or the gradual evolution of a solution, but is a revolutionary approach that upends the status quo. The last launch this big was in 2009 when we created Pagely. We’ve done amazing things since then, but nothing as innovative as what I’m announcing right now. Today, again, we’re changing the world of hosting. We’re proud to announce a revolution in Managed WordPress Hosting: NorthStack Serverless — an elastic, autoscaling, serverless platform for hosting WordPress, Node, and static sites. WordPress users can now build and run dynamic, interactive websites with plugins in a scalable, pay-as-you-go environment. Let’s break that down a bit. Pay-as-you-go and only pay for what you use Users of traditional hosting plans may face a lose-lose proposition. If the site’s demand is high, the performance of the site suffers. If demand is low, the hosting company pockets the extra from the unused resources. NorthStack frees clients to pay for only what they use in terms of compute resources, database, bandwidth, storage, and other essential elements of a successful WordPress site. For the first time, WordPress users are free to choose their overhead instead of being beholden to the whims of the host. Of course, traditional hosting plans from top-tier providers still have their place. NorthStack is not an attempt to put an end to that pricing model. The pricing model we use at Pagely, one that aligns with the needs of annual budget minded enterprises, isn’t going anywhere because it’s what allows us to provide the unparalleled support experience that differentiates us from other solutions. What NorthStack offers is better suited to a wider swath of the marketplace. Agencies, developers, and sites big or small with unpredictable traffic will know exactly what resources they are consuming, have complete budgeting control over them, and be billed only for what they actually use. Support is a la carte as well – allowing customers to scale their infrastructure, without scaling support costs. Serverless hosting NorthStack is a brand-new containerized (Docker) hosting stack that integrates a spectrum of serverless functions and serverless infrastructure components, including the AWS Aurora Serverless database service. The resulting combination allows NorthStack to provision, measure, and elastically autoscale hosting resources to customers on a metered-consumption billing model. “Serverless still uses servers!” the snarky among you are screaming — and cloud hosting has nothing to do with a rainy day. Just as cloud hosting saved consumers from having to worry about physical servers, Serverless will save customers from having to worry about virtual machines. Think of it as an infinite ocean of hosting resources that you can pull from as needed, without any of the hassles or limitations of a dedicated server or virtual machine. For several years, Pagely has provisioned Managed Hosting on individual Amazon EC2 instances which provide the security, performance, and privacy our Enterprise customers demand. A downside of the static nature of a VPS is having to stop and restart the instance to scale it up or down. Another drawback is the inherent waste of over provisioned resources, which also applies to the database backends. NorthStack maintains the security and performance benefits of VPS by isolating customers to unique containers while allowing these containers to elastically grow and shrink in a real-time, nearly seamless way, always right-sizing allocated resources based on demand. The platform goes beyond the limits of traditional hosting plans by providing CPU, memory, disk, and data transfer as individually metered resource streams. WordPress… and more! We are expanding from our core focus on WordPress to also provide managed hosting for headless WordPress sites with React/Vue front-ends, static sites and forthcoming support of Node.js, Laravel, and generic PHP sites. This will combine all the benefits of a managed environment with the flexibility to run the software of your choice. So if you’re running a WordPress site, you’re going to benefit from our expertise in high-demand Managed WordPress Hosting. We put everything we’ve learned about WordPress security, speed, and optimization to work for you with NorthStack. The path to NorthStack has been a fantastic and rewarding journey for us. We started as the first-to-market Managed WordPress host. And almost since launch, we’ve been consistently recognized as the leader in the now-mature channel we defined. NorthStack will be run as a bit of a separate entity from Pagely with its own account, support, and billing systems. Today we take the next step in delivering a new, powerful, genre-defining solution to address customers’ hosting needs. Since NorthStack is a Pagely product, you know you’ll be in a good hands. Regardless of whether you’re a Pagely Enterprise customer or a new NorthStack customer, you’ll experience the care, integrity, and professionalism that has made us successful. NorthStack is now available in a limited Beta program that tech savvy users are welcome to join. A special ‘thank you’ to a few WordPress community members that assisted with alpha testing and sanity checking this idea: Aaron Jorbin Scott Bolinger Gabor Javorszky Craig Martin Zachary Brown, Phil Crumm, and Vasken Hauri of 10up. Pippin Williamson Mario Peshev and Brian Krogsgard Press Release Pagely Announces NorthStack, the World’s First Truly Serverless WordPress Environment Disrupts WordPress Application Hosting With Instant Scaling, Unlimited Sites and Pay-As-You-Use Pricing AWS-Based Environment Provides Boundless Scaling with No Plans or Start-up Fees Full, Interactive Serverless Feature Set for Dynamic Sites Liberates WordPress Users from the Burden of the Webhost TUCSON, Ariz. — October 16, 2018 — Pagely, the flexible managed hosting service for business-critical WordPress projects, today announced NorthStack™, its new managed serverless application platform built on the AWS stack. In an unprecedented first, WordPress users can now build and run dynamic, interactive websites with plugins in a serverless, pay-as-you-go environment. NorthStack is available immediately in early beta on a limited basis. General availability of NorthStack will be announced in the first quarter of 2019. “Traditional hosting plans stick users with a lose-lose proposition,” said Pagely CEO Joshua Strebel. “If demand is high, performance suffers. If demand is low, the hosting company pockets the extra. NorthStack frees clients to pay only for what they use in regards to compute resources, database, bandwidth, storage, and all other essential elements of a successful WordPress site. For the first time, WordPress users are free to choose their overhead, instead of being beholden to the whims of the host.” Dynamic, Serverless and Elasticity Scalable NorthStack features boundless scalability with no plan change, restart or customer intervention required. Instead of relegating the serverless environment to static WordPress sites, a common trade-off for automated scaling, NorthStack retains all of the dynamic features that make WordPress such an effective site platform. Users can see their resource consumption via real-time usage metrics and decide for themselves whether to serve the site more slowly and pay less, or serve it faster and pay more. Additional features include: The ability to deploy WordPress, Headless WordPress with React/Vue front-ends, or static sites with ease. Independently metered CPU, database, storage and data transfer High availability [HA] with a multi-availability zone, globally distributed network routing and best practice “Blue-Green” deployment process Clients will be able to decide on the maximum number of PHP workers to control their spend Many of the existing benefits of Pagely’s full-service VPS offering Pagely is a safe, full-featured hosting environment backed by decades of expertise. An entire hosting tech stack built and monitored by one of the industry’s most experienced WordPress teams, NorthStack will live alongside Pagely’s full-service VPS offerings. “NorthStack removes some of WordPress’s biggest obstacles,” said Pagely CTO Joshua Eichorn. “Security-wise NorthStack has the privacy of a VPS without the wasted spend of over-provisioning and having to spin up your own instances of AWS. It truly is the north star of the future of WordPress.” For more information, or to apply for early access to the platform, please visit NorthStack.com. About Pagely Pagely is the leading managed WordPress hosting provider for high-demand websites. Founded in 2009, Pagely offers premium, service-oriented hosting that can accommodate even the most complex and sophisticated high-traffic WordPress websites. Pagely clients range from growing tech companies and creative agencies to universities, non-profits, and governmental institutions. For more information, please visit: https://pagely.com/ or follow us at: https://twitter.com/Pagely or https://www.facebook.com/Pagely. Media Contact Treble Michael Kellner treblepr.com Marks “northstack” is a pending registered trademark with the USPTO.
A look back – and forward. We launched Pagely in August 2009. Now, nine years later, Managed WordPress Hosting is a multi-billion-dollar channel. I’m not sure even we saw that coming back then. The channel grew slowly at first, then quickly took off to become saturated with providers of all stripes. Managed WordPress is now ubiquitous. Some providers are interesting, but very few are doing anything different, or better, for customers. The once-novel features of automatic updates, routine backups, robust site caching, and a focus on information security have been commoditized. Pagely has moved to the top of the market by deploying more robust and flexible solutions aimed at higher ed, media, and enterprise-tier clientele. Our expert-level staff cater to the complex technical and service needs of these clients by leveraging unique technical solutions crafted from almost a decade of “in the trenches” experience and an arsenal of resources available to us from our primary technology partner, Amazon Web Services. How We Roll (It’s Evolution, Baby) As the WordPress Hosting space became more crowded, we realized differentiation was the key to our growth. Instead of chasing volume, we drove forward with a focus on platform flexibility and a “white glove” concierge approach to service. Our tagline was “like a five-star hotel for WordPress,” emphasizing our values of professionalism, quality of service, and competency. Our guiding light was never to be the biggest hosting company out there, but rather to be the best hosting company possible. And I can comfortably say we’re succeeding at that mission. Today, we provide hosting to some of the biggest (Time Warner, VISA, Disney, etc.) and coolest (99designs, UNICEF, Sprout Social, etc.) companies and organizations in the world. We’ve grown steadily year-over-year despite never taking on outside funding. When the trend was to zig, we zagged. As WordPress ascended, and the competitive waters became frothy as hundreds of millions of dollars in venture capital (VC) flooded the space, we narrowed our focus to serving only the top third of the channel. We specialized in high-demand WordPress sites. “We help big brands scale WordPress” became our calling card as our client ranks swelled with household names, generating tens of millions in revenue to sustain us into the future. We serve our market with a flexible and consultative approach that allows us to deploy solutions specific to the needs of individual clients. This is a slower approach to growth than a typical high-volume hosting company; however, it has allowed us to focus on quality of service in key areas that matter to high-end clients–sales, support, onboarding, and engineering. We’re proactive and service-oriented and our customers love us for it. We’re not for everyone, but if you need WordPress to work and don’t want to worry about it, no one does it better than us. The “path less traveled” has been fruitful. No VC funding means we only answer to ourselves and to our customers. We routinely put the interests of our customers above profit (try doing that with investors!). No affiliate or paid referrals may mean fewer mentions on review sites and, perhaps, fewer referrals, but we prefer genuine endorsements from customers that know us and believe in us. By running a mostly remote organization, we’re able to hire the best and the brightest, and keep them happy through a positive work/life balance. We’re a very different sort of company in that we believe when you put people first, and focus on integrity and authenticity, good things will come. Thankfully, that formula has worked for us. Good things continue to come our way. People First We’ve been successful as a company–and as individuals–by intentionally fostering a culture that values critical thinking, fairness, and competency. Our priorities elevate the customer and the employee to the same status as profit. These can–and should–be mutually inclusive. We are a people-first company. The technology powering our hosting, while critical, is secondary to our focus on finding, caring for, and keeping the right people to help our customers. The right people are the ones who are not only skilled and experienced, but, more importantly, genuinely care about our customers and want to provide the best possible service to them. Everything else–our technology, our support, our sales process–grows out of that foundational value. A core tenet of that culture is that our team members are responsible for managing themselves on a day-to-day basis while being fully accountable to the team as whole. They are given our complete trust to make and execute decisions within their universe of responsibility. Our team(s) excels within this framework. Our Tech Stack Throughout 2017 and 2018, we’ve rebuilt our entire stack–investing in our sustainability and continued innovation with forward-thinking, value-driven decisions. Rebuilding the plane while flying it, as they say, while striving to deliver even more value to our clients. The ARES web application gateway is a core component of Pagely’s architecture, as it provides a faster, more flexible environment than that of other Managed WordPress Hosting companies. Pagely spent most of 2017 developing ARES to better serve the billions of requests to Pagely-hosted websites. The primary functions of ARES include routing, intelligent caching/acceleration, security, and configuration flexibility. For our customers, it means we’re able to create a completely custom hosting environment for them–something other companies can’t manage. Along with technologies like PHP7, HTTP/2, and SSL management, Pagely uses proprietary NGINX/OpenResty HyperProxies to deliver unmatched speed and Redis to further accelerate the WordPress experience. Our suite of in-house services includes: PressDNS: Premium DNS powered with Amazon’s route 53 service that takes advantage of geo-balancing and geo-routing PressCACHE: A global WordPress acceleration system that works much like a CDN, but is specifically designed to cache and serve WordPress page output PressARMOR: Pagely’s security architecture, including a web application firewall, malware scanning, chroot user separation, and network edge rulesets PressTHUMB: On-demand image optimization and thumbnail creation PressFORMANCE: Performance monitoring analytics and assessments Pagely’s tech stack continues to evolve through excruciating attention to detail while disregarding what is new/trendy or inexpensive/profitable. We’re interested in what works–efficiently, reliably, and securely–for our customers. What’s Next… Is Coming Soon! WordPress software will continue to improve in all areas and its market share will continue to grow. Because of this, hosting companies of all stripes will continue to pop up and existing solutions will try to improve their offerings to serve the expanding market. We aren’t resting on our laurels while things change, we’re getting ahead of the changes. In a few weeks we’ll be announcing a completely new and, dare we say, revolutionary Managed Hosting solution–one that builds on a decade of experience serving the WordPress ecosystem. This new service will be a departure from our current model of premium high-touch, low-volume hosting services. But it’s still a Pagely solution, so it’s deeply infused with our core principles of fairness and quality combined with our top-tier, battle-proven tech stack and the unique solutions we’ve developed for fast, reliable, secure hosting. Hosting plans at most other providers are all about profit. Artificial limits such as pageviews or other constraints push customers into higher plans to the benefit of the provider. Bait and switch selling practices are rampant, and the obfuscation of infrastructure are all some of the issues Pagely’s new service aims to address. Pagely has earned a reputation built on quality, integrity, and expertise. However, our current pricing model is out of reach for those most in need of these qualities in a host. With this new service, we aim to deliver this high level of value at a more palatable entry price–saving more WordPress site owners from the abuses of the industry. “You have the most skilled support techs of any company I have used. Your people just solve problems that others struggle to even diagnose.” –Dale Reardon Dale has been an on again, off again, customer of Pagely for many years. While he knows firsthand the value we deliver, budget constraints leave him unable to utilize our services long term due to our pricing model. He bounces between Pagely and several lower-cost providers who disappoint, returning to us for short stays as funding allows. In a sense, we created this new service for Dale and customers like him. Tesla started with an exclusive and premium-priced electric roadster that led to the more feasible, but still premium-priced, Models S and X, finally arriving at the mass market Model 3. Each iteration provides a 100% Tesla experience even as the entry price for buyers has dropped. We aim to do the same: Take everything we’ve learned over nine years in Managed WordPress and make it available to more people. Nine years ago we set the gold standard for Managed WordPress Hosting. Now we are betting on lightning striking twice. For the past year, our team–some of the top minds in the industry–has been hard at work on something that will, again, revolutionize the WordPress Hosting space while fixing many of the common shortcomings and complaints. If you’re an agency, developer, etc., you’re going to want to pay attention to this one. Stay tuned: follow us on Twitter for an announcement coming October 16, or opt in for email updates.
Over the last few years, we’ve undergone a complete rebranding of the Pagely website. It was a total re-do of everything. Our primary goal was to not just improve the aesthetics of our site, but the sales performance of it as well. Get more people seeing the information we want them to see, and ultimately buying our service or engaging our sales team. How do you know when a design is working? Test and measure everything. We have used Optimizely for some time to test copy, placement, and other factors to drive engagement. One aspect of this process is knowing and understanding where the user’s mouse is on the page, whether they scroll down through your copy, which buttons are being clicked, and where. Optimizely lets you track that data but not very easily. Enter CrazyEgg I’ve known about CrazyEgg for some time however we just recently added it to our tool chest. CrazyEgg is a simple but powerful tool to create Heatmaps and other mouse tracking reports. This data allows you to see your site from your user’s point of view in some respects. This heatmap shows us what parts of the page are getting attention or clicks and which are not. The nice thing about CrazyEgg is it works with Optimizely. We were testing two variants of the page with Optimizely and with a simple click both were imported as new snapshots into CrazyEgg. To scroll or not to scroll? I’ve heard from many people that “below the fold is dead,” or the other side “Let them scroll.” Perhaps on mobile, but at least our data shows that folks don’t scroll down as much as we would think. The Green and Blue areas here are just below the fold of the page. This Scrollmap shows us that fewer than 25% of users scroll down more than 600px’s. Perhaps time to rethink the layout a bit? The biggest win with CrazyEgg is that it’s smart enough to distinguish multiple clicks to /signup. There are a few ways to to get there, and CrazyEgg maps those clicks to their specific button whereas solutions like Google Analytics just lump them all together. We’ve Used CrazyEgg, and perhaps you should too. The product is simple, which is why it works. It gives you deep and actionable data that you can use to increase engagement and conversions on your page. Most times the best products do one thing really well. *This is an honest to goodness legit review. We are not affiliates or otherwise being monetarily compensated.
This article covers our public notifications related to major security issues our clients and the WordPress community should know about. We are always focused on prevention and the mitigation of risk to our clients, and keeping you updated here is part of that process. List of Vulnerable Plugins During This Month Plugins Removed From the Repository WordPress security team decides to close a plugin when a security issue is found and the developer doesn’t release a patch in a timely manner. You can read more about this here. If you are using one or more of the above plugins we recommend deactivating them until the developer releases a patch for the mentioned vulnerability or consider a more reliable alternative. Relevant Vulnerabilities Ti-woocommerce-wishlist : Authenticated WP Options Change A critical vulnerability was found in this plugin that when exploited allows an attacker to: Change the site options Create malicious redirects Escalate privileges (login as an administrator) This issue was resolved in the free version 1.21.12 on October 16, however when checking the premium version we noticed it was still vulnerable and was finally resolved on October 28 after we reported it. More details here. WPBakery Page Builder : Authenticated Stored XSS WPbakery Page Builder former Visual Composer had a medium vulnerability in versions before 6.4.1 that was only exploitable by high privilege users. Nevertheless we recommend all its users to update to the latest version. Loginizer : Unauthenticated SQL Injection Loginizer had an unauthenticated SQL Injection in versions before 1.6.4 caused by a lack of filtering before executing a database query. An attacker just had to craft a request with a malicious username. More information here.
Pagely is thrilled to announce our partnership with Object Cache Pro. Utilizing state of the art compression technology, Object Cache Pro is now part of Pagely’s core offering, and available to all of our customers, platform wide. Offering major cost savings, access to some of the world’s best technology, and a dedicated DevOps team to personalize your setup, Pagely customers can look forward to continued scale and growth, with no hosting friction. A first of its kind partnership, Pagely is proud to help fund innovation in this WordPress space by investing part of our budget into working alongside the fantastic team at Object Cache Pro. We’ve already seen great gains with Object Cache Pro and our customers can look forward to more in the future! Why Object Cache Pro? Before Object Cache Pro, we faced two challenges with sites making use of an object cache – CPU overhead and network saturation. The underlying technologies in Object Cache Pro solved both of these problems for us, translating to less money spent on server hardware and fewer situations where the (quite generous) AWS network limits are reached. With Object Cache Pro’s state of the art technology utilizing the Zstandard compression library from Facebook, without a lot of CPU overhead, compression is now done at the extension level, talking to and from Redis. This means less hardware, lower costs, and a better experience for our customers. Aside from supporting an efficient compression algorithm (zstd), Object Cache Pro also uses the igbinary serializer which is a drop-in replacement for the standard serializer in PHP. This works about twice as fast at serializing and unserializing data. Additionally, the data footprint is smaller when using igbinary and that translates into less memory being used by the underlying Redis service. We also found an in-depth comparison on igbinary vs other serializers on Blobfolio that you may also enjoy reading if you’re into this kinda stuff: https://blobfolio.com/2017/03/benchmark-php7-serialization/ With a wide selection of Redis plugins available in the WordPress marketplace, Object Cache Pro was the obvious choice for us not only because of their forward-thinking tech but also because of the dependability we have come to expect and appreciate from their brilliant team. All of this aside, Object Cache Pro is unrivaled when it comes to bug fixing, an extent to which is a rarity across opensource software. There’s a saying in the opensource community that goes, “there’s a lot of eyes so all the bugs get fixed.” But, more what we see concentrated use of the software by lots of users leading to fewer bug fixes for fear of breaking one users’ site. That, and, no one owns the codebase, so less can get addressed in a timely manner. Similarly, we are continuously impressed by their coverage of testing, fully unit tested with 100% code coverage. Further, switching over to Object Cache Pro gives Pagely customers access to our commercial relationship with their team, which means any problems our customers see are fixed within a few days. You benefit from our relationship. Fewer bugs in the caching layer and full unit testing is a good thing, and that’s something we stand behind. So, What’s in it for the Pagely Customer? We are the first premium host to achieve this level of partnership with one of the best technology companies in WordPress. Through our relationship with Object Cache Pro, every single Pagely customer benefits from the work we’ve done to secure that. But real talk, what’s in it for you? Major cost savings. Even when it means less revenue for Pagely, we’re constantly looking out for cost savings for our customers. By decreasing our dependency on more hardware, you see the savings directly on your bill. Access to a premium partner. Since you’re at a premium hosting provider, you automatically get access to the partnerships we’ve developed. What’s more? You don’t pay an extra licensing fee. The best tech, baked into your Pagely account. We’re always on the hunt for the best and most innovative technology for you. With no effort on your part, we do the legwork of implementing this tech across our technology stack. All you do is benefit from it. Bigger performance wins possible with a little extra code work. WordPress has a feature called Transients. It’s a way to store the result of a complex query or a long-running remote API call temporarily in order to make subsequent lookups for that data return a lot faster without doing the same expensive operation again. Normally without any object cache, transients are stored in the WordPress database’s wp_options table. When using an object cache, it is stored in memory. Adding a few extra lines to your code allows you to tap into the power of this API for incredible performance gains. Having an efficient object cache utilizing fast compression and serialization only increases those gains. A dedicated DevOps team. While others might catch on and jump on the bandwagon of partnerships like this, Pagely still stands above the rest in meaningful ways that translate to real gains for you, the customer. Our DevOps staff becomes your dedicated, in-house team. Our engineers handle all the setup and optimization to make sure your usage of Redis is optimized specifically based on your exact circumstances and needs. Other hosts don’t do that! When you partner with Pagely for your WordPress hosting at scale, you know you have selected the most forward-looking host driven by advances in technology, cost savings for you, and tangible outcomes that help your business thrive. Object Cache Pro Helped FanSided Scale So let’s get to a real-life example here. One of the first Pagely customers we switched over to Object Cache Pro was FanSided. Here you can see a dramatic decrease in network utilization on the Amazon Aurora RDS instance after implementing Object Cache Pro along with custom Transients Caching, which dropped usage from 1 Gigabit per second to 400 Megabit per second; and yielded even lower usage after some more optimizations were made. FanSided comprises a massive network of over 300 active websites and needed a fast solution to maxing out servers and using way too much CPU. Pagely found that solution in Object Cache Pro and implemented it with no effort on FanSided’s part to completely eliminate those issues. Here you can see how memory is no longer being maxed out after the date we turned on Object Cache Pro for FanSided. The proof is in the data, and here you can see dramatic drops in CPU usage after Object Cache Pro was implemented, as well as servers being maxed-out-no-more after the switch. Dramatic drops in CPU usage after implementing Object Cache Pro for FanSided. Read the full FanSided + Object Cache Pro case study here, and take it from our CEO: “In the vacuum of 1 website, a small performance gain is useful. At our scale of hosting, processing hundreds of billions of requests per month across thousands of AWS EC2 instances, a small performance gain to each site means a real and quantifiable benefit to our customers and our bottom line. Now what if that performance gain was not so small, but major. We sought out and partnered with Object Cache Pro after seeing the dramatic results in terms of performance and resource usage when testing. We have thus deployed their Enterprise solution fleet wide and the results speak for themselves.” – Joshua Strebel, CEO of Pagely
Catch up on the conversation. This piece comes as a followup to our CEO Joshua Strebel’s recent piece on why you should never pay your WordPress host for pageviews. Managed WordPress hosting has exploded across the hosting industry since Pagely created it way back in 2006. Overall, the level of innovation that the mainstream has brought to WordPress is amazing. Unfortunately, this sometimes comes with negative side-effects. As investors demand higher profits, many of these managed WordPress hosts are looking for ways to gain a quick and easy boost to their margins. Like we mentioned in our definitive guide to PHP workers, there are a few different metrics that are often misinterpreted, whether intentionally or not. Today, we’re going to talk about pageviews and their role in the managed WordPress hosting world. What Counts as a Pageview? Many hosts cite pageviews as a billing metric with vague term descriptions, if any exist at all. Even with clarified definitions, pageviews tend to mutate on a host-by-host basis with a dizzying array of buzzwords. Although individual managed WordPress hosts vary on what they consider a “pageview”, most define it like this: pageviews are the number of unique IP addresses that access pages on your WordPress site per day, excluding known bots. (Yeah, I know. The term is more like “the number of unique request sources per day, based on predefined catch-all filters.” But I wasn’t the one that made this up, so bear with me here.) Pageviews as a Billing Metric Before we dig in any deeper into the details, let’s think about the definition that I mentioned. Considering that narrative, which of these sites would be more expensive to host? A directory website that houses billions of pages, showing 1,000 entries at a time. A personal blog who’s majority of traffic is to single posts. A documentation site where visitors typically access multiple pages per day. A simple informational website for a local restaurant. An online shop that sells small-batch artisanal snake oil. An API that uses headless WordPress to dynamically fetch content. If you guessed that they represent the same metrics in the eyes of pageview-based billing, your logic prevails! Assuming that they all experience the same number of unique visitors, they’re all treated the same way, regardless of how resource-intensive the site is or how many pages each visitor accesses. Of course, it would be silly to treat all of these sites the same way. Some pages might have large amounts of fully dynamic content, while others might be eternally served from cache. Using an umbrella term like pageviews as a billing metric causes several different issues, based on the site being hosted. Setting Realistic Expectations The first issue that pageview-based billing causes is an unrealistic expectation for low-performance, unoptimized sites. If you’re not familiar with how WordPress sites perform on the server side, you might think that these limits matter exclusively and use them to determine what capabilities you need from a hosting provider. If you’re evaluating your hosting options purely based on a pageview limit, you’re ignoring critical factors that can dramatically impact your WordPress site. Performance-Based Punishment What if you’ve put hard work into optimizing your site? Well, now you’re wasting money on a billing metric that doesn’t matter. If your site is highly cacheable, you’re feeling the impacts even further. When serving content from cache, it’s practically free from a hosting perspective. You’re being nickel-and-dimed for something that is entirely outside of your control. Knowledge is Power As you scale, knowing what you’re paying for can quickly become a critical part of maintaining a healthy, cost-effective site. Coupled with the fact that the same people who are charging for pageviews tend to hide their underlying infrastructure behind the curtains, there’s no way to verify or manipulate what’s being counted. While many claim that they exclude the known IP addresses and user agents of known bots from counting towards your monthly pageview bill, what’s their motivation for even bothering? After all, more pageviews mean more money in their pockets. Pageviews Are Still Helpful Many of our prospective customers ask, “How many pageviews can ‘x’ plan handle?” Like we mentioned earlier, the impact of each pageview dramatically varies based on the type of content viewed and how your site was developed. Every WordPress site is different. It would be impossible to accurately estimate the ideal hosting environment without a complete understanding of what your site’s usage looks like. Although pageviews are a faulty metric as far as billing is concerned, they can still be useful as part of a larger dataset. Whether you’re scaling, optimizing for better performance, or shopping for a new hosting provider, pageview data plays a role in getting a full picture of your site. For example, if you were running benchmarks to determine your server’s capacity, pageview data could be used to identify what a typical day looks like. Let’s say your site looks something like this: 10% of traffic is on the home page. 30% of traffic is to various landing pages. 30% of traffic is to different blog posts. 20% of traffic is to your product’s pricing page. 10% of traffic is on account-related pages. Using that traffic data, you could then estimate what types of content have the most significant impact on server resources. You may find that some pages underperform and could use some optimization, while other highly-cacheable content, like blog posts or landing pages, remain essentially free. If 90% of your traffic goes to fully-cached content, increases in traffic have a trivial impact on your bottom line, if any. Closing Remarks Operating a WordPress site at scale is all about a delicate balance of performance and cost. At Pagely, we partner with our clients to help them achieve those goals. While shopping for a new hosting provider, be on the lookout for hosts that impose false barriers, such as PHP worker limits and pageview counts. Those vague limitations are a red flag that they’re going to try to upsell you later. (These limitations are also a sign that they’re trying to sell you on shared hosting resources too, but that’s a topic for another discussion entirely.) We hope that you’ve learned more about the impact of pageviews (or lack thereof) and why it’s not an appropriate billing metric. Do you have any experiences with pageview-based billing that you’d like to share? Is there something we missed? Let us know in the comments below.
This monthly report is provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core No notable WordPress core security releases. Plugin/Theme Vulnerabilities of Note Security & Malware scan by CleanTalk https://wpvulndb.com/vulnerabilities/10292 This vulnerability within CleanTalk allows an authenticated user, such as an editor or subscriber, to make unauthorized Ajax calls which could lead to file deletion or downloads and also potentially function calls. Adning Advertising https://wpvulndb.com/vulnerabilities/10293 The Adning Advertising plugin has a vulnerability in versions lower than 1.5.6 which allows unauthenticated requests to upload or delete files, leading to an RCE attack, which can then lead to full site takeover. Wise Chat https://wpvulndb.com/vulnerabilities/10299 Wise Chat versions lower than 2.8.4 are susceptible to a CSV injection via a command sent in chat messages by an unauthenticated user that is included in an exported CSV file, which then could potentially lead to an RCE attack. Email Verification for WooCommerce https://wpvulndb.com/vulnerabilities/10318 The Email Verification for Woocommerce plugin prior to version 1.8.2 is affected by a loose comparison issue. This could potentially lead to any user (authenticated or non-authenticated), to log into the WordPress site. SRS Simple Hits Counter https://wpvulndb.com/vulnerabilities/10316 The SRS Simple Hits counter plugin is currently vulnerable to an unauthenticated blind SQL injection vulnerability. The responsible reporting parties at Tenable ( https://www.tenable.com/security/research/tra-2020-42 ) are working with the developer to write a more comprehensive patch to address this vulnerability, and will not release more details on the attack until they know a patch has been released. Site owners using SRS Simple Hits Counter plugin on their sites should keep an eye out daily for the patch to be released. Payment Form For Paypal Pro https://wpvulndb.com/vulnerabilities/10287 The Payment Form for Paypal Pro plugin versions before 1.1.65 are vulnerable to an unauthenticated SQL injection attack. The attack is a trivial single request which can expose the contents of your database (which includes user passwords and potentially other secrets) to the attack. This is a high risk vulnerability and site owners should patch immediately. WooCommerce Subscriptions https://wpvulndb.com/vulnerabilities/10330 The WooCommerce Subscription plugin is vulnerable to an unauthenticated stored cross site scripting (XSS) attack in the subscription billing process. Attackers can submit their XSS attack payload to during the billing step in the signup process, and later that payload will be executed on the browser of the administrator/user who reviews the attacker’s account. Site owners should update WooCommerce Subscriptions plugin to version 2.6.3 and not check any new user account information until that update is performed. TC Custom JavaScript https://wpvulndb.com/vulnerabilities/10325 The TC Custom Javascript plugin is vulnerable to an unauthenticated stored cross site scripting attack. Sites running versions before 1.2.2 should update immediately, attackers can add their own javascript or HTML to the footer of all pages loaded by WordPress with a few basic requests. This vulnerability is likely to be targeted by SEO spam bots. KingComposer https://wpvulndb.com/vulnerabilities/10297 The KingComposer plugin is vulnerable to a reflected cross site scripting vulnerability in versions before 2.9.5 This means the attacker’s malicious HTML/javascript will only be available to the browser making this request. This still poses a high risk if an attacker can trick an already logged in user to click on a malicious link/form to the website, potentially exposing secrets viewable by the user giving them to the attacker. JobSearch https://wpvulndb.com/vulnerabilities/10328 The JobSearch plugin versions before 1.5.6 are vulnerable to a reflected cross site scripting vulnerability. Much like the KingComposer vulnerability above it is a high risk if logged in users to be targeted. The proof of concept for this vulnerability will be released on August 6th, 2020, site owners should patch before this date. See previous months’ WordPress security updates from May and June.
The benefits of this WordPress security guide are two fold: Learn exactly what you need to know about WordPress security in 2020. Understanding WordPress security helps you adopt a security-oriented mindset that will help you prevent and mitigate risks as you make day-to-day decisions. Get actionable, step-by-step instructions for securing your WordPress site. The steps you need to take aren’t particularly time-consuming, don’t require advanced technical knowledge, and the linked guides are vetted for clarity and completeness. Of course, it’s impossible to cover every possible vulnerability and scenario. That’s why we also include the overarching “principles of WordPress security.” If you can follow these broad principles many of the minute details that are difficult to address in this type of post will take care of themselves. Why is WordPress security critical? It’s important you understand how big an issue WordPress security is so you give it the time and attention it deserves. Here are some sobering statistics: Google blacklists 10k sites a day for malware and another 50k for phishing each week. A blacklist from Google kills that source of traffic which can be highly disruptive to a business’s revenue. Fixing and removing a blacklist can be a hassle, particularly if your server was used to send SPAM emails. A blacklist from email service providers harms your deliverability rate which undermines the effectiveness of your email marketing. In 2018, 90% of CMS hacks were WordPress. Granted, WordPress is the world’s most popular CMS with 34% of the web powered by WordPress, but this is still a disproportionate amount of hacks. For a variety of reasons, WordPress sites are targeted and exploited more than any other CMS. 60% of attacks target small businesses. You may think that hackers won’t bother with your site because you’re a small fish but “security through obscurity” does not exist on the web. No one is too small to be a victim of an attack. WordFence reports that there are over 97,978 attacks happening per minute. This is not a small, isolated problem. Large swaths of WordPress sites are being probed for weaknesses at any given time. Will you be ready if your site is targeted? While these stats paint an intimidating picture of what you’re up against, it’s important you confront the realities of managing a WordPress site in 2020. If your business relies on WordPress, security is not something you can afford to ignore. If you haven’t taken steps to secure your site, you’re vulnerable to attack. It could be only a matter of time until your site becomes compromised. This is one area where “an ounce of prevention is worth a pound of cure.” The principles of WordPress security Securing WordPress is more than checking off a list of boxes, it requires you to adopt a security-oriented mindset that guides your decision making. These principles will help you prevent mistakes as you make day-to-day decisions like adding new WordPress users, plugins, and themes: Vulnerabilities are often introduced by WordPress users. Vanilla WordPress that is kept up to date and uses strong passwords is relatively secure. It’s often the decisions made by WordPress users that create weaknesses that hackers exploit. This is why articles like this one are so important. It’s up to you to be educated on, and consistently follow, the WordPress security best practices outlined here. Minimize plugins and themes. New WordPress users are often overjoyed by the extensive ecosystem of plugins and themes available for WordPress. This can lead to indiscriminate installation of plugins. But, each new plugin or theme adds code to your site that, potentially, adds new vulnerabilities. By minimizing the plugins and themes installed, you also minimize the amount of code your site uses, and, by extension, the number of potential security vulnerabilities. In general, if you can solve a problem without installing a plugin, that’s the best option. Install updates as soon as possible. Updates to the WordPress core and updates to plugins and themes often contain critical security updates. They should be installed as quickly as possible. If you have a good back up strategy in place, you can roll back to a previous version in the event the update causes issues. Follow the principle of least privilege. This is a core principle of cybersecurity in general and is not unique to WordPress. This is a fancy way of saying, “don’t give a user more privileges than they need because those extra privileges give hackers more power and access than they’d otherwise have if they compromise that account.” Attacks can still happen. You can try as hard as you can to cover all the bases and still fall victim to an attack. This is why regular, automated backups are critical. Do not ignore this advice. A hacked site can be disruptive but can generally be fixed with minimal cost and disruption, a hacked site without a backup to roll back to can be severely disruptive. You are never finished with security. Having a 100% secure WordPress site is an impossible task. You can’t accomplish complete risk elimination, so aim instead for ongoing risk reduction. This “risk reduction” mindset prompts you to continue taking steps to improve your security as part of an ongoing, never-ending initiative. The most common WordPress attack vectors Understanding the most common methods hackers use to exploit WordPress will help you understand how to address them and why the steps recommended later in this article are necessary: Brute Force Attack A cyber criminal uses trial and error to identify a password or pin. They use combinations of common usernames and passwords until they find the right one. It’s the equivalent of trying every key on a key ring to find the one that works. This is all done using a computer script so they can run thousands of combinations with very little effort. Given enough time, any account is hackable but strong passwords thwart this kind of attack. SQL Injection Malicious SQL code is injected into a database to gain access to database information that was never intended to be displayed. Depending on the hackers goals, this can lead to your database being deleted, customer information being stolen, or sensitive company information being accessed. Malware A virus or spyware is inserted using an expired theme or plugin. The attacker can gain access to your data, insert pages into your site for black hat SEO, and perform a number of other nefarious activities using your site. Cross-site scripting Javascript code is inserted which then collects data commonly used to exploit WordPress plugins. This can be used to redirect your site visitors to malicious content. also known as an “XSS attack.” DDoS Attack A Distributed Denial of Service (DDoS) attack floods a website with traffic which overwhelms server resources causing it to fail. Multiple machines send frequent requests to the server using malware installed on those machines for that purpose. The distributed nature of the attack can make it difficult to identify and block the sources of the traffic. Now that you understand how hackers will attempt to breach your site security, let’s look at how we can block and prevent these attacks… Steps to secure your WordPress site In spite of the many ways your site can be compromised, it is possible to mitigate these risks and prevent many attacks. Here’s a list of recommended steps to protect your WordPress site from security attacks: 1. Force Strong Passwords “81% of attacks are based on insecure or stolen passwords” “It only takes about 10 minutes to crack a lowercase password that is 6 characters long.” These two facts taken together make the case that you must use strong passwords for all WordPress users. Strong passwords are long and use a combination of upper and lower case letters, numbers, and symbols. Longer is better but 20-characters is probably plenty. Strong passwords are difficult to memorize, especially if you’re using unique passwords for each site (you should be!). This means a password manager, such as LastPass or Dashlane, is a critical tool. These apps make creating strong passwords easy, store them in a central location, and make logging into your websites easy by autofilling your passwords. Here’s how to make sure all your WordPress users are using strong passwords. 2. Turn on automatic WordPress Core updates One of the advantages of using a popular CMS like WordPress is that there are many people with a vested interest in keeping it secure. Thousands of people are contributing to WordPress security by reporting vulnerabilities to the WordPress team. This widespread collaboration means most holes are patched relatively quickly. But, if the updates that contain those fixes are not applied, you leave your site vulnerable to attack. The best way to ensure your WordPress core updates happen quickly is to turn on automatic updates. This way your WordPress site will be kept up-to-date without you having to do anything. Here’s how to turn on automatic core updates by modifying your config.php file. 3. Stay on top of plugin and theme updates You absolutely must keep your plugins and themes up-to-date. The importance of this cannot be overstated. You’ll also want to be careful to use plugins and themes that are updated often. If you’re using a plugin or theme that has not received an update in months, it’s a good idea to check in with the developer or find a more frequently updated plugin that accomplishes the same goal. When you search for a plugin in the WordPress plugin database, this information is provided in the sidebar: 4. Use Two-Factor Authentication (2FA) Two-factor authentication adds a layer of protection to your WordPress site by making it nearly impossible for a hacker to log in to your site — even if they know your username and password. You should set up 2FA for all WordPress users. 2FA can be set up quickly with simple, free plugins. Here’s a list of available 2FA plugin solutions for WordPress. 5. Brute Force protection Even with 2FA and strong passwords, it is good to setup brute force protection to help with overall performance on the server by reducing the amount of work PHP has to do. Here’s how to protect your site from brute force attacks. 6. Create automated, scheduled Backups In the event of an issue, there should always be recent database and file backups available. You should also create a backup before making any major changes to your site, such as installing plugin and theme updates. Many of the popular backup solutions take care of this for you. Here’s a list of backup solutions for your WordPress site 7. Change your login pages The default login pages for all WordPress sites are sitename.com/wp-login.php and sitename.com/wp-admin.php. Using these default login page URLs makes it easy for hackers to begin a brute force attack by trying combinations of usernames and passwords. By using a login URL that is difficult to guess, it makes it more difficult for hackers to begin the brute force attack because they don’t know where the login form lives. Here’s how to change your login page URLs. 8. Use SSL Secure Sockets Layer (SSL) encrypts all data sent from your website to the visitors browser obscuring potentially sensitive data. Using SSL has many benefits in addition to security. Google may rank your site higher in the search results and many browsers indicate whether a site is secured by SSL which can reassure them your site is trustworthy. Here’s a tutorial on setting up SSL for your WordPress site 9. Don’t use the default database prefix Using the default “wp_” database prefix makes it easier for a hacker to insert code into your database (SQL injection). Here’s how to change the default database prefix for a new site and an existing site. 10. Check your folder and file permissions File permissions define what actions can be applied to the files on your server. You should never set any WordPress file or directory to 777 permissions. Instead, make sure your permission scheme is as follows: Folders – 755 Files – 644 Here’s a guide to checking and fixing the permissions of your WordPress files and folders. 11. Disable pingbacks WordPress pingbacks are enabled by default. But for most sites, they offer little benefit. But, they can be used to turn your WordPress site into an unwilling participant in a DDoS botnet. To turn off pingbacks, you can go to “Settings –> Discussion” and uncheck the “Attempt to notify any blogs linked to from the article” box. It’s also a good idea to uncheck the “Allow link notifications from other blogs (pingbacks and trackbacks) on new articles” box: 12. Hide your WordPress version number One of the ways attackers gain access to a site is by exploiting known vulnerabilities in outdated versions of WordPress. Hackers can scan your site and easily find out what version of WordPress you’re using. If that version has a known vulnerability then the hacker has a good idea of how to proceed. The best way to prevent this is to keep WordPress up to date. However, you can also prevent a hacker from finding out what version of WordPress you’re running. Here’s how to hide your WordPress version number. 13. Don’t use the admin username Hackers can safely assume that a WordPress site is using the default “admin” username and that username will give them admin privileges so all they need to do is figure out the password. This gives them a direct path to gaining admin access to your site with a good probability of success. Eliminating the admin username makes it significantly more difficult to attack your site this way. If you’re already using the admin username, that’s okay, you can change it now. Here’s how to change the admin username. 14. Use a secure Managed WordPress Host A host that supports all the major CMSs will have difficulty staying on top of WordPress security. By specializing in the WordPress CMS alone, a WordPress hosting provider can devote the resources necessary to prevent many attacks. A reputable Managed WordPress Host will have a security team dedicated to shielding your site from threats. They’ll handle many of the concerns raised above like taking care of WordPress updates, creating backups, and more. Here at Pagely we have a comprehensive suite of security features called PressArmor that handles both WordPress application security and server security. Security questions to ask a potential managed WordPress host: Is your hosting environment chrooted? If your host has multiple domains on the same server, check with them to ensure they use chroot to isolate each WordPress app. If one app is hacked, this would help prevent access to other apps on the server. Is SSL included and easy to set up? A good WordPress hosting provider will provide SSL free of charge using a service such as Let’s Encrypt. Do you actively monitor my site specifically for WordPress vulnerabilities? If you detect a vulnerability on my site, how will you inform me? A good WordPress host will stay on top of the latest threats to WordPress sites and constantly scan your site for those threats. If they find a vulnerability, they will work with you to address it. Are you using a web application firewall (WAF) to protect my site? A WAF block malicious traffic before it reaches your site and can help prevent XSS attacks and SQL injections. Here’s a list of important considerations for choosing a Managed WordPress Host. Conclusion WordPress security cannot be taken lightly and you must take steps to secure your site. Using a Managed WordPress Hosting Provider like Pagely is one of the best ways to improve your security because you will have an experienced team dedicated to protecting you. Whether you choose to handle WordPress security yourself or leverage a host that specializes in WordPress, it’s important to treat WordPress security as an ongoing effort. You are never done with security but if you’ve taken the above steps you’ve protected yourself from many of the most common threats.
