RunCloud CMS

Author: RunCloud Team

  • How to Optimize Your Site for Google’s Core Web Vitals

    How to Optimize Your Site for Google’s Core Web Vitals

    According to StatCounter, Google dominates the search engine market with an overwhelming 93.37% share, leaving its closest competitor, Bing, with just 2.81%. This market dominance highlights the critical importance for developers to optimize their sites for Google’s ranking algorithms.

    To rank websites Google employs a variety of methods, including the most recent and crucial method – Core Web Vitals, which began rolling out in June 2021.

    Core Web Vitals assesses website performance with metrics such as page loading times. It’s worth noting that a delay of just one second in page load times can lead to a significant reduction of up to 20% in a website’s conversion rates.

    It is therefore vital for any website developer to understand how these web vitals are measured, and what they can do to optimize their site to boost both their performance, and their position in the SERPs. In this article, we will identify exactly what Google’s Web Vitals are, how they impact your site, and how you can improve your site’s score.

    Let’s get started!

    Understanding Google’s Core Web Vitals

    Google’s Core Web Vitals consists of a set of specific website performance metrics that are used to determine the overall user experience of a website.

    It is a combination of three main parameters that measure specific aspects of page speed and responsiveness. These metrics include:

    1. Visual load, measured by largest contentful paint (LCP)
    2. Visual stability of web pages, measured by Cumulative Layout Shift (CLS)
    3. Interactivity, which is measured by First Input Delay (FID)

    The Core Web Vitals are part of Google’s Page Experience Ranking Signals, which also include factors such as mobile friendliness, browsing safety, HTTPS, and Intrusive Interstitials (or popups).

    A study from Google found that when a site meets the optimal thresholds for the three Core Web Vitals metrics, users were 24% less likely to abandon page loads. On top of that, they found a 22% decrease in news site abandonments and 24% fewer abandonments of shopping sites.

    The Two Types Of Data Used For Core Web Vitals

    Before we get into the optimization of sites, it is necessary to understand the kinds of data processed for measuring Core Web Vitals metrics. The two main types of data are:

    Field Data

    Field Data is generated from the Chrome User Experience Report (CrUX) and includes real user metrics. Google collects information from Chrome users who have opted to share information, such as browsing history, and uses the data to compute the three Core Web Vitals metrics. The aim is to understand how real-world Chrome users experience the web.

    You can see a summarized view of your site’s Core Web Vitals under the Google Search Console, and your page-level metrics in PageSpeed Insights under the Field Data category. However, you should note that this data is based on a rolling 28-day average, which means that any change in your site won’t be reflected in your Field Data report for around 28 days. This is where Lab Test Data comes to the rescue.

    Lab Test Data

    Lab Test Data is generated by tools that are designed to run tests consistently under the same conditions. Because of factors such as internet speed and geographical location this data does not reflect real-world data. You can view your site’s Lab data with the Lighthouse Chrome extension.

    The metrics are assessed at the 75th percentile of users. For example, if we look at the Page Speed Insights for the Gumroad site we will see that all Core Web Vitals metrics have greater than 75% results, so the site passes the Core Web Vitals assessment. If one or more metrics have less than 75% positive loads, it does not pass the Core Web Vitals assessment.

    Another thing to note is that metrics are measured by device type, meaning that mobile Core Web Vitals will be assessed separately from desktop ones.

    Before analyzing and optimizing the Core Web Vitals, it’s essential to assess the other basics of Google’s page experience signals, such as mobile friendliness and the use of HTTPS. We must remember that the Core Web Vitals are just a part of Google’s page experience signals.

    You need to take care of basic optimizations for page speed, such as having good hosting, compressing your images, caching your content, and setting up a Content Delivery Network (CDN). All of these things will inevitably contribute to improving your site’s Core Web Vitals.

    Core Web Vitals Metrics

    Largest Contentful Paint (LCP)

    Largest Contentful Paint tells us about the visual loading performance of a website. It measures the time it takes for the web page’s main content to load. LCP is simply the single largest visible element loaded in the viewport, which is the area of a web page visible to a user. You should aim to minimize this metric as much as possible – the recommended target is to have your LCP under 2.5 seconds.

    Cumulative Layout Shift (CLS)

    Cumulative Layout Shift measures the visual stability of a web page. CLS looks at how much visible elements have shifted in the viewport as remaining elements are loaded, and measures the distance the affected elements were shifted. In some web pages pop-up ads and videos appear out of nowhere and shift the content, which is annoying and results in a bad user experience.

    Previously, CLS was recorded continually to measure stability even after the page had loaded. But recently Google has revised the way CLS is measured; it is now calculated in terms of 5-second sessions. The metric that is reported is the 5-second timeframe in which the most shifting occurred. The recommended threshold by Google is to have a score of less than 0.1.

    First Input Delay (FID)

    First Input Delay measures interactivity. The purpose of this metric is to gain an understanding of a user’s first impression of a site’s interactivity and responsiveness. It measures the time from when a user first interacts with a page to the time when the browser is able to respond to that interaction.

    Different types of interaction will include clicking a link or a button, inputting text into a blank Field, selecting a drop-down menu, etc. The recommended speed for First Input Delay is anything under 100 milliseconds.

    Measuring Your Website’s Core Web Vitals

    A variety of browser extensions, tests, and reports are avaiLable that will help you analyze your site’s Core Web Vitals. Here are some of the most important ones.

    Core Web Vitals Assessment in Google’s PageSpeed Insights

    PageSpeed Insights is a tool developed by Google that reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved. It has two sections:

    • Core Web Vitals assessment lets you discover what your real-world users are experiencing
    • PageSpeed Insights score helps you diagnose performance issues with the help of Lab data

    This Core Web Vitals assessment is part of the Field Data report. The Diagnostics section in PageSpeed Insights also provides useful information about elements that affect each of the three Core Web Vitals metrics.

    PageSpeed Insights uses Lab data in addition to real user metrics to calculate the overall optimization score, and also provides suggestions for improvements.

    You should note that in some cases PageSpeed Insights doesn’t provide a Field summary. This usually happens for small websites because the Chrome User Experience Report cannot collect enough Field data. Fortunately there are other sources that will provide you with Field data.

    Core Web Vitals Report In Google’s Search Console

    Google’s Search Console Tools is a web service by Google that allows users to measure a site’s traffic and performance, fix common issues, and make the page perform better in Google search results.

    Google Search Console has two Core Web Vitals reports, tailored for both mobile and desktop versions. Each of these reports provides you with the Field data for a group of URLs, and offers insight into their performance. These reports are beneficial for finding common issues and similar errors across a group of URLs. This ensures you get information about the entire site – instead of just information on one page at a time.

    For example, if you have many product pages where the largest element is an image or a banner, the Largest Contentful Paint (LCP) metric will be similar for all of them. In such a case, Google Search Console finds LCP issues across all of these identical product pages.

    In the console you can alert Google after resolving any Core Web Vitals problem by clicking on Validate Fix.

    Using the Core Web Vitals Chrome Extension

    Chrome’s Core Web Vitals extension offers a quick way to check your Core Web Vitals. This extension automatically gives you a brief audit of Largest Contentful Paint, Cumulative Layout Shift, and First Input Delay. It can audit the website’s performance for other users compared with its performance on your own device.

    Using Chrome User Experience Report For Extracting Field Data

    Gaining access to the Chrome User Experience Report (CrUX) requires more time and effort than simply running your site through PageSpeed Insights or Google Search Console. However, going through this report also provides more ways to organize and visualize your site’s Field data.

    There are two main ways to directly access the CrUX dataset:

    1. BigQuery: This method requires a Google Cloud project and SQL expertise
    2. The Chrome UX Report API: This method requires some developer experience with both JavaScript and JSON

    If you can afford the time and possess the technical expertise, it is worth experimenting with both methods above.

    Optimizing Your Site For Core Web Vitals

    After measuring your site’s Core Web Vitals, the next step is to optimize it for them. You need to keep in mind that every website is built differently, and we can’t possibly fix every potential problem. Below we’ll discuss several tried and tested techniques for improving web performance.

    It is important to keep in mind that your site’s performance can also be affected by factors that aren’t discussed here. You always need to examine your specific problems before implementing any optimizations.

    Analyzing and Optimizing Largest Contentful Paint (LCP)

    As discussed above, Largest Contentful Paint (LCP) measures the time it takes for the largest element in the viewport to load. Anything below 2.5s is considered to be a good LCP score. If the largest viewport element loads faster than that for 75% of all recorded page loads, the web page passes the LCP assessment.

    A quick and easy way to check which element triggers the LCP metric is to run the page through PageSpeed Insights. In the dashboard, scroll down to the Diagnostics section and click on the Largest Contentful Paint element.

    The same can be done with Chrome’s DevTools. For this, open the page you want to inspect in Chrome, right-click and select Inspect, then go to Performance. Now, click on the Reload button, and wait for the browser to examine the page.

    Core Web Vitals Metrics

    You’ll be able to locate a small LCP icon in the Timings section. When you hover your cursor over it, the largest element of the page will be highlighted with a blue shade.

    For additional insight you can use a waterfall chart to see how many resources were loaded before the LCP. Here’s how the waterfall chart looks for our example website, Gumroad, created using GTmetrix:

    Tips To Improve LCP Time

    Here are a few measures you can take to improve your LCP load time:

    1. Optimize your images: Inefficiently formatted and very large images are often the biggest reason for slow websites. For faster loading, images must be properly converted to the right format, compressed, and resized. Lossless compression maintains roughly the same image quality while reducing the size of the image file.
    2. Preload hero images: Hero images are usually the most prominent above-the-fold elements, so loading them quicker is crucial for a fast and responsive user experience. This tells the browser to prioritize the specific hero images when rendering the web page.

    Preloading significantly improves LCP, especially on pages where hero images are loaded with JavaScript and the background-image property in CSS. Browsers usually discover these images later, so using link rel=preload helps improve both actual and perceived performance.

    1. Find a better hosting plan: Using a cheap, shared hosting plan will always lead to slow execution times because of the slow host server. Upgrade your hosting plan to have a fast server response time, and both stabilize and speed up your site.

    If you are looking for a new hosting solution, consider using RunCloud for managing your servers.

    1. Implement Critical CSS: Critical CSS is a technique that extracts the viewport content in order to render content to the user as quickly as possible. Critical CSS finds the CSS necessary to load above-the-fold content and inline it in the <head> tag. Doing so improves both actual and perceived performance.
    2. Use a Content Delivery Network (CDN): Using a CDN splits the load by hosting assets on servers that are geographically closer to the users, thus greatly improving a site’s performance.

    Analyzing And Optimizing Cumulative Layout Shift (CLS)

    We already know that Cumulative Layout Shift measures the effect of unexpected layout alterations in a web page that occurs when content moves around the page without user input. A visually stable page maintains a CLS score of 0.1, and if that’s true for the 75th percentile of recorded page loads, the web page passes the CLS assessment.

    Google computes the CLS score by measuring how much of the viewport the layout shift affected, and how far the elements moved from their original position during the shift. The final CLS score is calculated as the total of all individual unexpected layout shift scores.

    Chrome’s DevTools can help detect unexpected layout shifts. You need to right-click on the page you want to analyze and select Inspect. Navigate to More Tools and click on Rendering. At the bottom of the Inspect console you’ll see a Layout Shift Regions option with a checkbox on the left. Click on the checkbox to ensure it’s selected.

    Now every time the layout of the page shifts, the shifted area will be highlighted in blue.

    This CLS generator tool is also great for discovering layout shifts. it computes your overall CLS score and shows shifting areas.

    Fixing Common CLS Issues

    Here are a few tips for improving your layout shifts.

    1. Add width and height attributes to images and videos: Adding attributes of height and width in the HTML markup enables the browser to allocate the correct amount of space for each element in advance. This renders a blank element in place of the image, and replaces the element with the actual image when it is loaded. This drastically reduces layout shift issues.
    2. Optimize Font Delivery: Unoptimized web font delivery can cause huge layout shifts. Using font-display: optional in combination with link rel: “preload” for the site’s most prominent fonts is typically considered the best practice. The optional value avoids causing a re-layout when the web font is ready, and this ensures a layout shift does not happen.
    3. Don’t insert ads and pop-ups on top of other content: Adding intrusive ads and pop-ups are the most common ways to ruin your CLS score. Many elements can cause this issue, including ads, promotional banners, search bars, etc. If you must place such elements on your page, implement them in a way such that it does not negatively impact the user experience.
    4. Reserve space for iFrames, ads, and dynamic content: These elements can cause significant layout shifts if they don’t have reserved space, just like images and videos. You need to use containers with proper dimensions and use the overflow: hidden property to make sure larger content doesn’t overflow its container.
    5. Make interactions faster: Make sure user interactions are completely executed within 500 milliseconds of the input trigger. Lightening up page loads by using OS fonts, compressing and preloading visual content, and using proper containers all prove to be helpful in making interactions faster.

    Analyzing and Optimizing First Input Delay (FID)

    We have already discussed that First Input Delay measures the time it takes for the browser to begin processing the first user interaction on a web page. However, scrolls and zooms don’t affect FID; this metric only keeps track of distinct actions such as clicks or taps. A low FID is crucial because first impressions leave a mark on the users, and most users instantly leave and, in most cases, never return if a website irritates them on their first visit.

    A web page’s FID should be less than 100 milliseconds for 75% of all recorded page loads for it to pass the FID test.

    The main culprit of FID issues is usually JavaScript. Excessive usage of JavaScript leads to Long Tasks. These are periods of time when the UI is unresponsive to user interaction. If the main thread is blocked for more than 50 milliseconds it is considered a Long Task.

    To find Long Tasks on your web page, open the page, right-click, and select Inspect. From the Inspect console, open the Performance panel and reload the web page. Now, you must click Main and select the Bottom-up analysis button.

    You will find the Long Tasks in the Main section. These tasks are usually painted in gray with a red overlay. The Bottom-Up analysis also lets you group files by URL, and helps you pinpoint what causes delays. In the above example, the first script alone takes more than 400 milliseconds, which is far too long.

    As you dive deeper into the Bottom-Up analysis, you’ll find that a few longer functions contribute to most of the delay. In some other cases, functions might be running quickly – but adding too many of them together in a single task converts into a Long Task.

    WebPageTest is another useful tool that provides an in-depth processing breakdown, helping you to find problem areas. It provides a detailed page summary which provides insight into the site’s performance, and helps you by providing information that allows you to tweak your site for a better Core Web VItals ranking.

    Fixing Common FID Issues

    There are multiple ways to minimize your First Input Delay. Some of the most popular ones include:

    1. Compress or minify code files: Removing unnecessary parts from the code such as whitespaces and line breaks (minification), and modifying and compressing code files to make them smaller helps significantly reduce FID.

    Minimizing third-party JavaScript requests for analytics, social media widgets, discussion forums, etc., that quickly mount up to several megabytes of JavaScript also helps with FID issues. There are some hosting services and CDN providers that implement these features by default, making the process easier for users.

    1. Break up Long Tasks: This is arguably the most effective way to reduce FID, as Long Tasks block the main thread from responding to user interactions quickly. By dividing them into smaller parts you can significantly improve the performance of your website. You can take advantage of JavaScript features such as requestCallback, setTimeout, and requestAnimationFrame to break long-running JavaScript tasks into a series of smaller tasks.
    2. Use web workers: Web workers enable web content to run scripts in background threads without affecting the main thread. It is generally considered a good practice to move non-UI operations to a background thread. Additionally, you can use asynchronous, deferred, or ESS module JavaScript to run some scripts later.
    3. Remove or delay non-critical third-party scripts: Sometimes third-party scripts can prevent your own scripts from executing on time. You need to prioritize the scripts according to their importance and rearrange their execution pattern. For example, if you are showing ads on your website, or if you are tracking user interactions, you should defer executing those scripts until the website is loaded.
    4. Optimize CSS: While JavaScript is the root cause of most FID issues, CSS is also render-blocking by default. Excessive CSS hurts the user experience, and you need to make sure you avoid expensive CSS properties such as box-shadow and filter. Besides implementing Critical CSS and minifying and compressing CSS files, it is also important to get rid of all unnecessary CSS on your site.

    After Action Report

    Google’s introduction of the Core Web Vitals was a major step in the right direction toward making the web better for everyone. The Core Web Vitals are important for all websites as part of Google’s page ranking algorithm.

    That is why it has become necessary to continuously monitor these metrics, even if you don’t notice any major issues right now.

    Going forward, here is a quick checklist of things that you need to remember:

    • You should run a test at least once a month.
    • Prioritize Field data over Lab test data, as the former accurately represents how actual users experience your site.
    • Make use of Google’s Search Console to find issues across a set of web pages.
    • Use PageSpeed Insights to understand and monitor how your site performs.
    • For a deeper understanding of your site’s performance and for further customization, extract data from the CrUX and gain additional control over your Field data.

    If you are looking for an easy and painless way to manage your web servers then you should start using RunCloud. RunCloud makes it easy to deploy new servers, update DNS records, deploy new WordPress sites, manage database users, monitor NGINX logs, and more. Start using RunCloud today!

  • Which is Better: Redis Full-Page Cache or NGINX FastCGI Caching?

    Which is Better: Redis Full-Page Cache or NGINX FastCGI Caching?

    Did you know that a one-second delay in page load time can reduce conversions by 7%?

    There is one simple solution to drastically improve the performance of your website…

    …caching!

    In this article, we will discuss what is caching, and compare two powerful caching solutions – Redis Full-Page Cache and NGINX FastCGI Caching.

    Let’s get started!

    A Primer on WordPress Caching

    Before we dive deep into the comparison, let’s quickly recap what caching is and how it works.

    In layman’s terms, caching is the process of storing frequently accessed information in a quickly accessible location, such as RAM or a disk.

    Storing this information allows the server to retrieve the data faster when someone requests it. This greatly reduces the page load times as the server needs to do fewer computations to generate all of the content from scratch.

    If you are interested to learn more about this topic beyond the scope of this article, then you should read our other articles on What is Object Caching and How To Use Redis Full-Page Caching To Speed Up WordPress.

    What Is Redis Full-Page Caching?

    Redis is an open-source database that can store key-value pairs in memory – this design makes Redis a great choice for caching data.

    Redis Full-Page Caching is a technique for caching WordPress data in such a way that it stores the entire HTML output of a web page in Redis cache memory. This means that when a user requests the web page, the cached HTML is retrieved from Redis memory instead of generating it from scratch, resulting in a faster response time.

    Redis full page caching can be enabled easily in the RunCloud dashboard. Just go to your web application dashboard and look for the RunCloud Hub setting. Install the RunCloud Hub plugin to automatically configure the settings.

    Once you have installed the plugin, you can change the lifespan of the cached content, or purge it directly from the dashboard.To learn more about this, read our article on How Redis Object Caching can improve your website’s performance.

    What Is NGINX FastCGI Caching?

    NGINX is a popular web server that is known for its high-performance and stability. NGINX FastCGI caching is a way to store the entire HTML documents to disk for easier access. When a user requests the web page, the cached HTML is retrieved from disk storage, resulting in a faster response time.

    NGINX FastCGI caching works by proxying requests from clients to an application server that uses a FastCGI protocol, such as PHP-FPM. It then serves all subsequent requests directly, without contacting the backend again for a specified amount of time.

    You can quickly start using this caching method – just go to your RunCloud dashboard and open the web application that you want to optimize. In the dashboard, look for the RunCloud Hub plugin and enable it.

    Once you have enabled caching, you can configure additional settings such as the lifespan of cached content, or see how much content has been cached already.To get a deeper understanding of the topic, we recommend you to read our tutorial on NGINX caching and How To Use NGINX FastCGI Cache.

    The Benchmarks – What The Data Shows

    Having a consistent test environment was our utmost priority to ensure we generated reproducible results.

    We deployed three identical WordPress websites running on PHP 8.2 on Ubuntu 22 LTS server to compare the performance differences between Redis Full-Page caching and NGINX FastCGI caching.

    On each website, we created a new webpage with 20 paragraphs of text and 2 images. All of the websites had SSL enabled and used identical themes without any additional plugins.

    Finally, all of the websites were tested with a sustained load, one at a time, under identical network conditions using Grafana k6.

    During testing, we paid close attention to the number of iterations, which told us how many web requests were completed successfully. We also checked 95 percentile scores of the iteration_duration metric – which told us how long it generally took to open the webpage. For instance, if the p95 score was 1.2 seconds, then it meant that 95% of all requests were completed in under 1.2 seconds.

    Let’s see the results!

    Unoptimized WordPress

    In our tests, we found out that our native WordPress instance could serve approximately 4.77K web requests, with an average request taking nearly 2.15 seconds. Upon closer inspection, we found that some requests were completed fairly quickly (1.1 seconds) while others took much longer (3.41 seconds).

    That’s not good. Let’s see if using a caching service helps.

    Using Redis Full-Page Caching

    Using Redis greatly increases the number of web requests served. In addition to a 2x increase in the number of requests, we also see an improvement in 95 percentile scores. The difference between minimum and maximum time taken to complete the web requests was almost 0. This would provide a much more consistent user experience while browsing.

    Redis Full-Page Caching test results

    Using NGINX FastCGI Caching

    While using NGINX’s FastCGI caching, we saw a similar improvement in the number of requests, and 95 percentile scores. Once again, the response times are lower and much closer to each other.

    NGINX FastCGI Caching test results

    Final Results – Which One To Use

    There is no clear winner. Our benchmark results showed that Redis Full-Page Caching outperformed NGINX FastCGI caching in terms of response time and the number of requests served per second – but only by the width of a hair. Both of these options are a significant improvement over native WordPress – our advice is that you can use either of them.

    It’s a no-brainer that using any type of caching is better than not using anything. Not only will it improve the performance of your website, but it will also reduce the load on your web server, allowing you to serve more customers without any additional increase in hosting costs.

    Both Redis Full-Page Caching and NGINX FastCGI caching are excellent caching solutions that can significantly improve website speed and performance. However, if you’re using OpenLiteSpeed server, you should also check out our article on LiteSpeed Cache WordPress Plugin.

    Transform your server management experience with RunCloud – the ultimate platform for simplifying website maintenance. RunCloud provides out of the box solutions for implementing caching, issuing SSL certificates, and streamlining your workflow. Sign up to RunCloud today to enjoy more control over your servers, automated backups, and robust security features.

  • How UptimeRobot Can Save Your Website from Downtime Disasters

    How UptimeRobot Can Save Your Website from Downtime Disasters

    Website monitoring is the process of checking the availability, performance, and functionality of a website.

    It’s an essential, and on-going task for web developers and owners to ensure that their websites are always online, fast, and user-friendly.

    Effective website monitoring can help detect and resolve issues, prevent downtime, improve user experience, and optimize website performance.

    UptimeRobot is a service that monitors your website’s uptime and alerts you when it goes down. By integrating UptimeRobot with RunCloud, you can monitor all of your websites hosted on RunCloud servers, and access a number of features and benefits from both.

    In this article, we will show you how to use UptimeRobot and RunCloud together for website monitoring. We’ll cover the following topics:

    Understanding UptimeRobot

    UptimeRobot is a service that monitors your website’s uptime and alerts you when it goes down.

    It achieves this by sending requests to your website at regular intervals and checking the response status code, response time, and keyword presence. If the response is not satisfactory, UptimeRobot will notify you via email, SMS, webhook, or other method of your choice.

    UptimeRobot has several features and benefits that make it a popular choice for website monitoring. Some of them are:

    • Free and paid plans: UptimeRobot offers a free plan that allows you to monitor up to 50 websites with 5-minute intervals, and 2 alert contacts. You can also upgrade to a paid plan that gives you more websites, shorter intervals, more alert contacts, advanced settings, and premium support.
    • Multiple types of checks: UptimeRobot supports different types of checks for your websites, such as HTTP(S), ping, port, keyword, and heartbeat. You can choose the type of check that suits your website’s needs – and customize the settings accordingly.
    • Various notification methods: UptimeRobot can alert you via various methods should your website go down or come back up. You can choose from email, SMS, voice call, webhook, Telegram, Slack, Discord, Pushbullet, Pushover, and more. You can also set different alert contacts for different websites and scenarios.
    • Status pages: UptimeRobot allows you to create public or private status pages for your websites. You can display the uptime and performance data of your websites on these pages, and share them with your visitors or clients if you wish. You can also customize the look and feel of your status pages with your own logo, domain name, colors, etc.

    Different Monitor Types

    UptimeRobot supports different types of monitors to check the availability, performance, and functionality of websites or web services. Here is a brief explanation of each type of monitor:

    • HTTP: This type of monitor sends an HTTP or HTTPS request to a website, and checks the response status code and response time. If the status code is not 2xx (success) or 3xx (redirection), or if the response time exceeds a certain threshold, the monitor will alert you that the website is either down, or slow.
    • Keyword: This monitor also sends an HTTP or HTTPS request to a website, but it checks the presence or absence of a specific word or phrase in the response body (typically HTML or JSON). You can choose to be alerted if the keyword is either found or not found on the website. This can help you verify the content or functionality of your website.
    • Ping: This type of monitor sends an ICMP ping packet to an IP address or a domain name, and checks both the response time and packet loss. If the response time is too high, or if there is no response at all, the monitor will alert you that the device is unreachable or slow. This can help you check the network connectivity and availability of your servers or devices.
    • Port: This type of monitor sends a TCP or UDP packet to a specific port on an IP address or a domain name, and checks if the port is open and listening. If the port is closed or filtered, the monitor will alert you that the service is down or inaccessible. This can help you check the status and performance of various services running on your servers or devices, such as email, database, FTP, SSH, etc.
    • Heartbeat: This type of monitor requires you to send an HTTP request to a specific URL provided by UptimeRobot at regular intervals from your own server or device. If UptimeRobot does not receive a request within a certain time frame, the monitor will alert you that the server or device is down or malfunctioning. This can help you monitor recurring background jobs or intranet devices connected to the internet.

    You can choose the type of monitor that suits your website’s needs, and customize the settings accordingly.

    Setting-up UptimeRobot

    To use UptimeRobot to monitor your websites, you’ll need to follow these steps:

    1. Sign up for a free or paid account on UptimeRobot, and log in to your dashboard. On the top left corner, click on “Add New Monitor” to create your first monitor.
    1. Provide a suitable name for your monitor, and enter the URL of your website that needs to be monitored. Here you can also specify the frequency of your tests and other basic configuration.
    1. Next, configure the alert settings by selecting the notification methods and contacts for each monitor. If your website experience crashes, these notification channels will be used to notify the specified contact(s).
    2. Optionally, you can create status pages for your monitors by choosing the template and options. Status pages are public pages that you can display to your customers or other stakeholders to track the health of your service.

    After you have performed the above steps, you can enjoy peace of mind – UptimeRobot will now keep an eye on your websites, and notify you if anything goes wrong.

    Understanding UptimeRobot Teams

    Team member functionality on UptimeRobot is a feature that allows you to add your team members to your UptimeRobot account, and assign them different levels of access and notification.

    You can use this feature to collaborate with your team members on website monitoring, and keep them informed of any issues or updates.

    There are two types of team members that you can add on UptimeRobot:

    1. Read or write access: These are team members who can log in to your UptimeRobot account with their own credentials and perform actions such as adding, editing, or deleting monitors, alert contacts, or status pages. You can choose to give them read-only or read-write access depending on their role and responsibility. You can also choose which monitors, alert contacts, or status pages they can access or manage.
    2. Notify-only: These are team members who cannot log in to your UptimeRobot account but can receive notifications via email, SMS, or voice call when your monitors go down or come back up. You can add them as alert contacts and assign them to specific monitors. You can also customize the notification frequency and content for them.

    Dos and Don’ts For Using UptimeRobot

    Here are some tips and best practices for website monitoring with UptimeRobot and RunCloud:

    Choose the right type of check and interval for your website

    Depending on the nature and purpose of your website, you may want to use different types of checks and intervals to monitor its uptime and performance.

    For example, if your website is a static HTML page, you may use a simple HTTP(S) check with a 5-minute interval. But if your website is a dynamic web application that relies on a database or an API, you may use a keyword or a heartbeat check with a 1-minute interval.

    Use multiple alert contacts and methods for different scenarios

    You may want to notify different people or teams when your website goes down or comes back online. For example, you may want to alert your web developer via email and SMS when your website goes down, but only alert your marketing manager via email when your website comes back up.

    You can also use different notification methods for different urgency levels. For example, you may want to use a voice call for critical issues, but only use a webhook for minor issues.

    Create status pages for your websites and share them with your clients

    Status pages are a great way to communicate the uptime and performance of your websites to your visitors or clients. These pages can help you build trust and transparency with your audience, and reduce the number of support requests.

    You can create public or private status pages for your websites using UptimeRobot, and customize them with your own logo, domain name, colors, etc.

    Don’t rely on a single type of monitor, or a single alert method.

    You may miss some issues or receive false positives if you only use one type of monitor or one alert method. You should use multiple types of monitors and alert methods to cover different scenarios, and ensure that you receive timely and accurate notifications.

    Don’t set unrealistic expectations for your website uptime

    You should understand that no website can achieve 100% uptime or perfect performance all the time. There are many factors that can affect your website’s availability and speed, such as network issues, server issues, code issues, traffic spikes, etc.

    You should set realistic and reasonable goals for your website uptime and performance, and measure them against industry standards and best practices.

    Final Thoughts

    Website monitoring is a vital part of your web development and maintenance strategy. It can help you ensure that your websites are always online, fast, and user-friendly. By using website monitoring tools such as UptimeRobot, you can detect and resolve issues, prevent downtime, improve user experience, and optimize website performance.

    But wait, there’s more! If you are looking for the best cloud hosting service provider for your websites, look no further than RunCloud.

    RunCloud is a platform that allows you to easily manage your web servers and web applications on any cloud provider.

    RunCloud lets you choose from a variety of cloud providers such as AWS, Google Cloud, DigitalOcean, Vultr, Linode, etc. and connect them to RunCloud with just a few clicks. You can then enjoy the benefits of RunCloud’s optimized web stack, backup, deployment, team collaboration, analytics, optimizer, and much more.

    What are you waiting for? Join RunCloud today and take your website hosting to the next level!

  • Synthetic Monitoring 101: How Datadog Can Help You Test and Optimize Your Web Services

    Synthetic Monitoring 101: How Datadog Can Help You Test and Optimize Your Web Services

    Is your website suffering from frequent outages and unexpected downtime? If yes, then you should look into Synthetic monitoring.

    Synthetic monitoring is a proactive way to monitor the performance and availability of your web applications and services by simulating user requests and actions from different locations. Synthetic monitoring helps you to:

    • Detect issues before they affect your real users
    • Ensure consistent user experience across devices and browsers
    • Measure service level agreements (SLAs) and objectives (SLOs)
    • Optimize your web performance and reliability.

    RunCloud allows you to manage your cloud servers with ease, and you can also integrate RunCloud with Datadog to monitor your server metrics, logs, and events.

    Datadog is a cloud-based platform that provides synthetic monitoring solutions for API, browser, and mobile tests. You can create and manage different types of synthetic tests with Datadog, such as API tests, multistep API tests, browser tests, or private locations.

    In this post, you will learn how to use Datadog and RunCloud together to monitor your web applications and servers with synthetic monitoring. You will also see how to create and manage synthetic tests with Datadog, analyze and troubleshoot synthetic test results with Datadog, and set up alerts, dashboards, and reports for your synthetic tests with Datadog.

    Let’s get started!

    Setting up Datadog and RunCloud

    Before you can use Datadog and RunCloud for synthetic monitoring, you’ll need to create an account on both platforms, and install the Datadog agent on your RunCloud server. Here are the steps to do that:

    • Creating an account on Datadog: Go to the Datadog website and click on the “Get Started” button.
    • Logging in to your server via SSH: You need to connect to your server with superuser privileges to install the monitoring agent. Read our guide on configuring SSH to learn more.
    • Install the Datadog agent on your RunCloud server: The Datadog agent is a tool that collects and sends metrics, logs, and events from your server to Datadog. To install the Datadog agent, follow these steps:
      • Go to the Datadog dashboard and click on the “Integrations” button.
      • Select “Datadog Agent” from the list and click on the “Ubuntu” tab to view the installation command.
    • Copy the Installation Script and paste it in your terminal. This will start the installation process – wait for the installation to complete.

    You have successfully set up Datadog and RunCloud for synthetic monitoring. After installation, the agent will start sending data within a few minutes. Once you get the message “Your first Datadog Agent is reporting. Congrats!”, you can click on the “Finish →” button to complete the installation.

    In the next section, you will learn how to create and manage synthetic tests with Datadog.

    Creating and managing synthetic tests with Datadog

    Synthetic tests are simulated user requests and actions that you can create and run with Datadog to monitor the performance and availability of your web applications and services. Datadog supports three types of synthetic tests: API tests, multistep API tests, and browser tests.

    • API tests: API tests are HTTP requests that you can send to your API endpoints and verify the response status code, body, headers, or latency. You can use API tests to check the functionality, performance, and reliability of your API endpoints. You can also chain multiple API tests together to create multi step API tests.
    • Multistep API tests: Multistep API tests are sequences of API tests that you can use to simulate complex user journeys or workflows involving multiple API calls. You can use multistep API tests to check the end-to-end functionality, performance, and reliability of your web applications and services. You can also extract variables from one API test and use them in another API test within the same multi step test.
    • Browser tests: Browser tests are user interactions that you can record and replay with a headless browser to monitor the performance and availability of your web pages. You can use browser tests to check the functionality, performance, and reliability of your web pages. You can also add assertions, variables, screenshots, or video recordings to your browser tests.

    In addition to this, you can also run tests from private locations. Private locations are dedicated machines that you can use to run synthetic tests from your own network or infrastructure. You can use private locations to monitor internal or private web applications and services that are not accessible from the public internet.

    To create tests with Datadog, follow these steps:

    • On your Datadog dashboard, click on “UX Monitoring” tab and go to the “Synthetics” page.
    • Click on the “New Test” button and choose the type of synthetic test you want to create: API test, multistep API test, or browser test.
    • Follow the instructions on the screen to configure your synthetic test settings, such as the test name, URL, frequency, locations, assertions, variables, screenshots, video recordings, etc.
    • Click on the “Save Test” button to save your synthetic test. After you have created a synthetic test with Datadog, it will be executed automatically according to the specified interval.

    Analyzing and Troubleshooting Synthetic Monitoring Results

    You can use synthetic test results to identify and resolve issues that affect your web performance and reliability. To access and interpret synthetic test results with Datadog, follow these steps:

    • Click on the synthetic test that you want to analyze. You will see the Test Details page, which shows the latest test result, and the historical test results for that synthetic test.
    • On the Test Details page, you can see various information about your synthetic test result, such as the test status, duration, response time, latency, errors, screenshots, video recordings, APM traces, etc. You can use this information to evaluate the performance and availability of your web applications and services. You can also compare different test results over time or across locations to identify trends or anomalies.
    • If your synthetic test result shows an error or a failure, you can use the Error Panel to see the details of the error or failure, such as the error message, stack trace, screenshot, video recording, APM trace, etc. You can use this information to troubleshoot and fix the issue that caused the error or failure. You can also click on the “Share” button to share the error details with your team or stakeholders via email or Slack.
    Synthetic monitoring dashboard Datadog

    Summary

    Synthetic monitoring is a proactive way to monitor the performance and availability of your web applications and services by simulating user requests and actions from different locations. In this post, you have learned how to use Datadog and RunCloud for synthetic monitoring.

    By using Datadog and RunCloud together, you can monitor your web applications and servers with synthetic monitoring in a simple and efficient way. You can also benefit from the features and capabilities of both platforms to improve your web performance and reliability.

    If you want to start using RunCloud for your web hosting needs, you can sign up for a free trial. RunCloud makes server management easy by providing you with a user-friendly interface, a powerful script installer, a robust security system, and a flexible backup system.

  • Using Dynatrace to Monitor RunCloud Servers

    Using Dynatrace to Monitor RunCloud Servers

    In today’s digital landscape, the smooth operation of web applications is crucial to business success, and the performance and reliability of your server infrastructure cannot be overstated.

    Server monitoring protects your applications against unexpected downtimes and performance bottlenecks, as well as valuable insights into the health, performance, and security of your infrastructure.

    Dynatrace is a cutting-edge observability platform designed to provide real-time insights into the performance of your web applications and the underlying server infrastructure.

    In this article, we’ll explore how to use Dynatrace to monitor your RunCloud servers, maximize uptime, and supercharge your web application’s performance.

    Let’s get started!

    Setting Up Dynatrace for RunCloud Servers

    Prerequisites

    Before you can start using Dynatrace to monitor your RunCloud servers, you’ll need to ensure you meet the following prerequisites:

    1. RunCloud Account: You should have an active RunCloud account with at least one server connected to it. If you haven’t set this up yet, visit the RunCloud docs for detailed instructions on getting started.
    2. SSH Access: Open your preferred SSH client or terminal. Use the SSH credentials associated with your RunCloud server to establish an SSH connection. Ensure that you have the required SSH access to execute commands on the server where you intend to install Dynatrace, and integrate it with your RunCloud-managed infrastructure. This access is essential for a successful Dynatrace installation and integration.
    RunCloud ssh login

    Once you have these prerequisites in place, you’re ready to move on to the installation process.

    Dynatrace Installation

    1. Access the Dynatrace Dashboard: Log in to your Dynatrace account and to view the Dynatrace dashboard. In the dashboard, look for the “Start collecting data” option. Click on it to begin the setup process.
    Dynatrace dashboard
    1. Choose One Agent: On the next screen, you’ll have the option to choose the type of agent you want to install. Select “One Agent“. On the next screen, click “Set up“.
    1. Generate PaaS Token: Since we’re working with a RunCloud server, choose the “Linux” option for the type of environment. After selecting the Linux option, you’ll be presented with instructions on how to generate a PaaS token. This token is essential for establishing the connection between Dynatrace and your RunCloud server. Click on the “Create Token” button to generate the PaaS token.
    Dynatrace agent
    1. Execute Commands: Once you’ve generated the PaaS token, a set of commands will be provided. These commands need to be executed in your SSH terminal on your RunCloud server. These commands will install and configure the Dynatrace agent on your server.

    Ensure that you follow each step carefully to complete the installation process successfully. Once the installation is complete, the Dynatrace agent will start collecting data from your server, and you will see your server in the Dynatrace dashboard.

    Monitoring Real-time Server Health

    After successfully installing the Dynatrace agent, you’ll need to wait for a few minutes to allow the data to populate in your Dynatrace dashboard. Once the data from your RunCloud server is connected and visible in Dynatrace, you can start taking advantage of the powerful features that Dynatrace offers.

    Creating Custom Dashboards:

    Custom dashboards in Dynatrace allow you to tailor the monitoring experience to your specific needs, helping you keep an eye on the most important metrics for your application. Follow these steps to create a custom dashboard:

    1. Create a New Dashboard: In your Dynatrace account, navigate to the Dashboard section. Click on the “+ Dashboard” button on the top left corner. Give your dashboard a meaningful name that reflects its purpose.
    2. Add Tiles: Within your dashboard, you can add tiles representing various metrics such as response times, error rates, CPU usage, memory utilization, and more. Click the “+” button on the top right part of the dashboard and select the metrics you want to monitor.
    1. Configure Tiles: Customize each tile by selecting the specific metric, filtering options, and visualization preferences. You can resize, move, and arrange the tiles to create an intuitive layout.
    2. Save Your Dashboard: Once you’re satisfied with your custom dashboard, save it. You can access this dashboard anytime to get a quick overview of the metrics that matter most to you.

    Setting Up Service-Level Objectives (SLOs)

    SLOs in Dynatrace help you define performance goals for your applications, and measure how well they meet those goals. To set up SLOs:

    1. Navigate to SLO Management: In the Dynatrace menu, find the “SLO” section (sometimes under “Settings” or a similar category).
    2. Create a New SLO: Click on “Create SLO” or a similar button to start creating a new Service-Level Objective.
    3. Define the SLO: Name your SLO, specify the application or service it applies to, set the target performance threshold (e.g., response time under 500ms), and choose the evaluation window (e.g., last 7 days).
    4. Save the SLO: Once you’ve configured your SLO, save it. Dynatrace will continuously monitor your application’s performance against the defined objectives.
    5. Review and Optimize: Regularly review the SLO performance data. If an SLO is frequently breached, consider optimizing your application or infrastructure to meet the defined objectives.

    Key Metrics to Monitor

    1. CPU Utilization

    Monitoring the CPU utilization of your servers is essential to understand their processing capacity and identify potential bottlenecks. This enables you to spot any spikes or consistently high usage that might indicate performance issues. By integrating Dynatrace with RunCloud, you can seamlessly access this critical metric, allowing you to make informed decisions about resource allocation – and ensure optimal server performance.

    1. Memory Usage

    Memory is a finite resource, and efficient management is crucial to maintain stable server operation. Having real-time insights into memory consumption trends allows you to identify potential memory leaks or unusually high usage patterns. This ensures that you can proactively address memory-related issues before they impact application stability.

    1. Network Performance

    Network connectivity is the lifeline of any web server. Monitoring network performance is vital to ensure smooth data transfer between servers and clients. Comprehensively tracking network performance metrics, such as latency, packet loss, and network throughput, allows you to detect network anomalies, troubleshoot connectivity issues, and optimize your application’s responsiveness to deliver a seamless user experience.

    Final Thoughts

    The old adage “prevention is better than cure” couldn’t be more applicable to server management. Dynatrace equips you with the ability to detect anomalies before they impact users, allowing you to resolve issues before they become critical.

    The proactive monitoring approach ensures that you stay one step ahead, maintaining a smooth user experience and reducing downtime to an absolute minimum.

    While Dynatrace supercharges your monitoring capabilities, RunCloud serves as an exceptional cloud management platform that simplifies server management, saving you time and effort. With RunCloud, you can effortlessly manage your servers, deploy applications, and enjoy a user-friendly interface that streamlines tasks. Start using RunCloud today!

  • How MailHog Can Transform Your Local Email Testing Process

    How MailHog Can Transform Your Local Email Testing Process

    Email testing is an essential part of any email marketing campaign. It allows you to check the quality, functionality, and deliverability of your emails before you send them to your subscribers.

    However, email testing can also be a frustrating and time-consuming process, and this is where local email testing can help.

    Local email testing means that you send your emails from your local development environment to your own email address, or to a test email account. This way, you can see how your emails look and behave in different email clients and devices without affecting your actual subscribers – or your reputation.

    Caveats with Traditional Email Testing

    It’s important to be aware that email testing can come with some common problems or challenges, such as:

    • Spam filters: Your emails may end up in the spam folder or be blocked by the email provider due to various reasons, such as invalid sender address, poor content quality, suspicious links, etc.
    • Delay in SMTP servers: Your emails may not be sent or received at all due to the limitations or errors of the SMTP server that you use to send your emails locally. You may have to configure the SMTP settings manually or use a third-party service to send your emails.

    These problems can make email testing a tedious and unreliable process. You may waste a lot of time and effort in testing your emails locally without getting the results that you want.

    That’s why you need a better way to test your emails locally.

    That’s where MailHog comes in.

    By the end of this article, you will be able to use MailHog to test your emails locally with maximum effectiveness. This will significantly help you improve the quality, functionality, and deliverability of your emails before you send them to your subscribers.

    Are you ready to learn how to use MailHog to test your emails locally? Let’s get started!

    What is MailHog?

    MailHog is a simple and powerful tool that can transform your local email testing process. It can easily help you test your emails locally without any hassle or headache, and can help you fix the problems that you’re currently facing when testing your emails locally.

    Why use MailHog?

    Local email testing can help you improve the quality, functionality, and deliverability of your emails before you send them to your subscribers. It can also save you time and hassle in testing your emails. Here are some of the benefits of local email testing:

    • It is instantaneous: You don’t need to wait for network delays or server issues to see how your emails look and behave. You can test your emails in real time and get immediate feedback.
    • It saves email quota. Sending too many emails might reduce your spam score or trigger spam filters. By testing your emails locally, you can avoid wasting your email quota or damaging your email reputation.
    • It prevents accidentally sending to real customers if there is a bug in your code. Sometimes, you may have errors or typos in your code that could cause your emails to be sent to the wrong recipients or with the wrong content. By testing your emails locally, you can catch these mistakes before they cause any harm or embarrassment.
    • It allows you to simulate situations where the communication between your program and the email server is interrupted or degraded due to various reasons, such as network congestion, packet loss, latency, etc. These faults can cause your emails to be delayed, corrupted, or lost. By testing emails locally you can create and control these network faults and test how your program behaves under these conditions.

    Jim: The Chaos Monkey

    MailHog comes with an interesting extension, Jim – a chaos monkey. It’s a tool that simulates random failures and disruptions in your email system. This is useful for testing the resilience and reliability of your email system, as well as your ability to handle, and recover from, unexpected errors.

    By inviting Jim to your email testing, you can expose and fix any weaknesses or vulnerabilities in your email system. You can also learn how to build better automatic recovery mechanisms, and improve the quality, functionality, and deliverability of your emails.

    For example, you can test how your program handles the following scenarios:

    • Rejecting incoming connections with a certain probability
    • Disconnecting sessions randomly
    • Applying a rate limit to connections
    • Rejecting authentication attempts
    • Rejecting a sender’s or recipient’s address

    By using these tools, you can see how your program reacts to different types of network faults – and whether it can recover from them gracefully. You can also improve your error handling and logging mechanisms and make your program more robust and resilient.

    How To Use MailHog

    Here is a step-by-step guide on how to install and set up MailHog on your local machine, and configure it to capture and display the emails that you send from your application:

    1. Download MailHog from its GitHub repository. You can choose the version that suits your operating system and architecture. For example, if you are using Windows 10 64-bit, you can download the file named mailhog_windows_amd64.exe.
    2. Save the downloaded file in a folder of your choice. For example, you can create a folder named mailhog in your C:\ drive and save the file there.
    3. Open a command prompt window and navigate to the folder where you saved the MailHog file. For example, you can type cd C:\mailhog and press ‘Enter’.
    4. Run the MailHog file by typing its name and pressing ‘Enter’. For example, you can type mailhog_windows_amd64.exe and press ‘Enter’. You should see a message saying that MailHog is listening on port 1025 for SMTP and port 8025 for HTTP.
    1. Open a web browser and go to http://localhost:8025. You should see the MailHog web interface, which shows the list of emails that MailHog has captured.
    1.  Configure your application to send emails to MailHog instead of your actual SMTP server. You can do this by changing the SMTP settings in your application to use localhost as the host name and 1025 as the port number.
      You can also use any username and password for authentication, as MailHog doesn’t check them. 

    For WordPress Sites

    There are many WordPress plugins that allow you to send emails using a specific mail server. You can configure them to use MailHog to test your email. After sending the email, you can view the email in the MailHog dashboard.

    For Generic PHP Applications

    If you are using PHPMailer to send emails from your PHP application, you can use the following code snippet to send emails to MailHog server:

    <?php
    // Load PHPMailer library
    require 'PHPMailerAutoload.php';
    // Create a new PHPMailer instance
    $mail = new PHPMailer;
    // Set Mailer to use SMTP
    $mail->isSMTP();
    // Set SMTP host name
    $mail->Host = 'localhost';
    // Set SMTP port number
    $mail->Port = 1025;
    // Set SMTP username
    $mail->Username = 'anyusername';
    // Set SMTP password
    $mail->Password = 'anypassword';
    // Set email subject
    $mail->Subject = 'Test email from MailHog';
    // Set email body
    $mail->Body = 'This is a test email sent from MailHog';
    // Set email sender address
    $mail->setFrom('sender@example.com', 'Sender Name');
    // Set email recipient address
    $mail->addAddress('recipient@example.com', 'Recipient Name');
    // Send email
    if ($mail->send()) {
        echo 'Email sent successfully';
    } else {
        echo 'Email sending failed: ' . $mail->ErrorInfo;
    } ?>
    1. Test your application by sending an email from it. You should see the email appear in the MailHog web interface. You can also open the email and check its content, layout, design, attachments, links, etc.
    MailHog dashboard

    Conclusion

    MailHog is a simple and powerful tool that can transform your local email testing process. In this article we have shown how to use MailHog to test your emails locally and fix the common problems or challenges that developers face when testing emails locally, such as spam filters, email clients, SMTP servers, etc.

    If you are looking for a great cloud management platform that saves time and doesn’t require you to be a Linux expert, we recommend you check out RunCloud.

    RunCloud is a modern web server panel designed to help you manage your PHP web applications and websites.

    With RunCloud, you don’t need to be a Linux expert to build a website, and you can host it on a cloud provider of your choice such as Vultr, Linode, UpCloud, Hetzner, AWS, Google Cloud or DigitalOcean.

    Start your free trial today and see for yourself how RunCloud can make your cloud hosting experience easier and better.

  • Setting Up Local WordPress Dev in Minutes Using Laravel Valet

    Setting Up Local WordPress Dev in Minutes Using Laravel Valet

    Laravel Valet is a local development environment for Mac users who want to create WordPress sites quickly and easily. It’s a lightweight, minimalist tool that uses the built-in PHP server and Nginx to serve your WordPress sites.

    Unlike other local development tools, such as MAMP, XAMPP, or Local by Flywheel, Laravel Valet does not require you to configure a virtual host, a database, or a port for each site.

    Instead, you can simply create a new site in any directory, and link it to a custom domain name (such as .test) with one command. It also provides automatic HTTPS for your sites, so you can test them securely and avoid browser warnings.

    Some of the features and benefits of Laravel Valet are:

    • Fast and easy installation: You can install Laravel Valet with Composer and Homebrew in only a few minutes. You don’t need to download or install any bulky software or packages.
    • Automatic HTTPS: Laravel Valet uses the mkcert utility to generate and trust SSL certificates for your sites. You can access your sites with HTTPS without any configuration or hassle.
    • Custom domain names: Laravel Valet allows you to use any domain name (such as .test, .dev, or .local) for your sites. You can link any directory to a domain name with one command, and access it in the browser.
    • Multiple PHP versions: Laravel Valet lets you switch between different PHP versions (such as 7.3, 7.4, or 8.0) with just one command. This enables you to test your sites with different PHP versions without affecting other sites or settings.
    • Custom drivers: Laravel Valet supports various frameworks and applications, such as WordPress, Laravel, Symfony, Drupal, etc. You can also create your own custom drivers for any application that you want to use with Valet.

    Laravel Valet is a great tool for WordPress developers who want to work locally with speed and simplicity. It’s especially useful for developers who work on multiple WordPress sites or projects at the same time.

    In this article, we will show you how to use Laravel Valet to set up a local WordPress dev environment in only a few minutes.

    Prerequisites

    Before you can use Laravel Valet to create and run WordPress sites, you need to have the following requirements:

    • A Mac computer: Laravel Valet is only compatible with macOS. You’ll need to have a Mac computer with macOS Sierra (10.12) or higher.
    • Port 80 is free: The websites will be served port 80 of your computer. You should make sure that no other programs, such as Apache or Nginx, are binding to your local machine’s port 80.
    • Supported PHP Version: Laravel Valet requires PHP 7.3 or higher to work. You can check your PHP version by running php -v in the terminal.
    • Composer: Composer is a dependency manager for PHP. You’ll need to have Composer installed on your Mac in order to install Laravel Valet and other tools.
    • Homebrew: Homebrew is a package manager for macOS. You’ll need to have Homebrew installed on your Mac to install some of the dependencies of Laravel Valet, such as Nginx and MySQL.

    These are the main prerequisites for using Laravel Valet. If you already have them, you can proceed to the next section. If not, you can follow the links provided to install them on your Mac.

    Installing Laravel Valet

    To install Laravel Valet on your Mac, you need to follow these steps:

    • Open the terminal and run the following command to install Laravel Valet using Composer:
    composer global require laravel/valet
    • Run the following command to install and start Valet:
    valet install
    • This command will install Nginx and Dnsmasq using Homebrew, and configure your Mac to use Valet’s drivers. It will also register Valet’s daemon to launch when your system starts.
    • By default, Valet will use the .test domain for your sites. If you want to use a different domain, such as .dev or .local, you can run the following command:
    valet domain <tld-name>

    For example, if you’d like to use .app instead of .test, run valet domain app and Valet will start serving your projects at *.app automatically.

    • To check if Valet is running properly, you can run the following command:
    valet status
    • This command will show you the status of Valet’s services, such as Nginx, Dnsmasq, and PHP. You should see something like this:
    Valet services are running:
    [OK] Nginx is running
    [OK] Dnsmasq is running
    [OK] PHP 7.4 is running
    • If you see any errors or warnings, you can run the following command to restart Valet:
    valet restart

    That’s it! You have successfully installed Laravel Valet on your Mac. You are now ready to create and run WordPress sites with Valet.

    Installing WordPress

    To create a new WordPress site using Laravel Valet, you need to follow these steps:

    • Choose a directory where you want to store your WordPress site. For example, you can create a directory called wordpress in your Sites folder:
    cd ~/Sites
    mkdir wordpress
    • Go to the directory and install WordPress using WP-CLI or Composer. You can use either of them to download and install WordPress core files and dependencies. For example, you can use WP-CLI to install WordPress with the following command:
    wp core download
    • Alternatively, you can use Composer to install WordPress with the following command:
    composer create-project roots/wordpress
    • Both commands will create a wp-config.php file in your directory. You can edit this file to configure your database settings and other options. You can also use WP-CLI or Composer to install plugins, themes, and other components for your WordPress site.
    • Use Valet to link your site directory to a custom domain name. For example, if you want to use wordpress.test as your domain name, you can run the following command:
    valet link wordpress
    valet open
    • This command will create a symbolic link between your site directory and the .test domain. You can also use a different domain name if you want.
    • Access your site in the browser. You can now visit your site by typing wordpress.test in the browser. You should see the WordPress installation screen where you can enter your site title, username, password, and email address. After completing the installation, you can log in to your WordPress dashboard and start building your site.
    • Use Valet to secure your site with HTTPS. If you want to use HTTPS for your site, you can run the following command:
    valet secure wordpress
    • This command will generate and trust an SSL certificate for your site using the mkcert utility. You can then access your site with HTTPS by typing https://wordpress.test in the browser. You should see a green lock icon in the address bar indicating that your site is secure.

    You have successfully created a new WordPress site using Laravel Valet. You can now enjoy the benefits of a fast and easy local development environment for WordPress.

    Troubleshoot Common Issues

    If you encounter any problems with Valet or WordPress, you can try some of the following solutions:

    • Restart Valet by running valet restart.
    • Check the status of Valet by running valet status.
    • Check the logs of Valet by running valet logs.
    • Check the configuration of Valet by running valet config.
    • Unlink and relink your site by running valet unlink wordpress and valet link wordpress.
    • Unsecure and resecure your site by running valet unsecure wordpress and valet secure wordpress.
    • Update Valet by running composer global update.
    • Update WordPress by running wp core update or composer update.

    Final Thoughts

    In this article, we have covered how to use Laravel Valet to set up a local WordPress dev environment in minutes. Laravel Valet is a great tool for WordPress developers who want to work locally with speed and simplicity. It’s especially useful for developers who work on multiple WordPress sites or projects at the same time.

    You can start using Laravel Valet to keep your site directories organized and consistent, such as using a naming convention or a folder structure to group your sites by type, client, or status. For example, you can use clientname-projectname.test as your domain name, or create a clients folder to store all your client sites. For more information and documentation on Laravel Valet, you can visit the official documentation.

    Another quick and easy way to set up a testing environment is by creating a staging site on RunCloud. RunCloud lets you focus on your product and takes care of server management. You don’t need to be a Linux expert to host a successful website, start using RunCloud today and see for yourself.

  • How To Set Up Free Self-Hosted Mailbox Using FreeScout On Your VPS [Open Source]

    How To Set Up Free Self-Hosted Mailbox Using FreeScout On Your VPS [Open Source]

    If you’re looking for a free and open-source solution to manage your customers, you might want to check out FreeScout.

    FreeScout is a web-based customer support system that lets you manage your email conversations with your clients and customers. You can also add modules for live chat, knowledge base, reports, and more.

    The official Wiki page provides detailed instructions and tips for installing FreeScout on a fresh server. However, if you’re using RunCloud to manage your servers, this process is much simpler. You don’t need to worry about installing and configuring any server software, such as Nginx, PHP, and MySQL. You can just create a web app on RunCloud – and follow the steps in this article to install FreeScout in minutes.

    By the end of this article, you’ll have a fully functional FreeScout system that you can use to provide awesome customer service. Sounds good? Then let’s get started!

    Step 1: Create an Empty Web Application

    First, you need to create a blank web app on RunCloud. A web app is a way of telling RunCloud how to run your website. To do this, you’ll first need to log in to your RunCloud dashboard.

    On the RunCloud dashboard, you will see a button that says “Create Web Application”. Click on it, and you will see a form where you can enter some details about your web app.

    You need to enter a name for your web app, such as “FreeScout”. You also need to enter a domain name for your web app, such as “freescout.example.com”. This is the address where people can access your website. You can either use your own domain name, or get a free one from RunCloud for testing purposes.

    After you enter the name and the domain, you will see some options for the application type and the public path. These are settings that tell RunCloud how to run your web app. For now, leave them as they are and click on “Create Web Application”. RunCloud will create a blank web app for you and show you some information about it.

    Step 2: Log in via SSH

    You’ll next need to connect to your server using SSH. After logging in, the first thing you need to do is change the directory to the web app root directory. This is the folder where your web app files are stored. You can do this by typing cd <path> and pressing “Enter“, where <path> is the path to the root directory of your web application – you can get this from your RunCloud dashboard.

    Step 3: Download FreeScout

    After that, you need to download the latest version of FreeScout on your server. To download FreeScout, visit https://github.com/freescout-helpdesk/freescout/releases/latest and copy the download link for the latest release. It should look something like https://github.com/freescout-helpdesk/freescout/archive/refs/tags/1.8.86.tar.gz.

    Next, you’ll need to use wget to download the zip file to your server. To use wget, type “wget” followed by the download link and press “Enter“.

    For example:

    wget https://github.com/freescout-helpdesk/freescout/archive/refs/tags/1.8.86.tar.gz.

    Step 4: Extract the Archive

    After downloading the file, type ls and press “Enter“. This will show you a list of everything that is present in the current directory. If you followed the steps correctly, your output will look something like this:

    Next, you’ll need to extract the files from the archive file. To extract the files, type tar -xf followed by the name of the archive file, and press “Enter“.

    For example:

    tar -xf 1.8.86.tar.gz.

    This will create a folder named freescout-x.x.xx, where x.x.xx is the version number of FreeScout. Inside this folder, you will find all the files and folders that make up FreeScout.

    Step 5: Move the Contents

    Next, you should move the files from the freescout-x.x.xx folder to the root of your application. You can do this by using cp -r followed by ./freescout-x.x.xx/* and . and press “Enter“. For example, your command should look something like this:

    cp -r ./freescout-1.8.86/* .

    This will copy all the files and folders from the freescout-x.x.xx folder to the current directory. After that, you can delete the downloaded file and the freescout-x.x.xx folder because you don’t need them anymore. You can also remove the default index.html file. You can do this by using rm -rf and then the name of the file or folder, and press “Enter“. 

    rm -rf freescout-1.8.86/
rm 1.8.86.tar.gz
rm index.html

    Step 6: Create the .env File

    The next step us to create a file named .env.example in the current directory. This file will store your FreeScout configuration settings, such as your database name and password. To create this file, run the following command: touch .env.example.

    Step 7: Update the Application Settings

    Next, you’ll need to update your web application settings. Go back to your RunCloud dashboard and click on the “Settings” tab. Under the “Stack” sub-section, you will see a option for the application type and the public path. These are settings that tell RunCloud how to run your web app.

    FreeScout uses the Laravel framework to run. The public path is the folder where your web app files are accessible from the internet. You should change the application type to Laravel and set the public path to /public.

    After you change these settings, click on “Update Stack”. RunCloud will apply the changes and restart your web app. As a result, you will see a new section of Laravel settings in the left menu.

    Next, scroll down to the PHP settings section, and look for the symlink function in the disabled functions list and delete it – make sure you delete the trailing comma as well.

    After removing the function from the disabled list, click on the “Update PHP Settings” button to save the settings.

    Step 8: Create a Database and User

    Finally, you’ll need to finish the installation by opening your web browser and going to your web app domain. You should see the FreeScout installation wizard. This is a page where you can enter some details about your FreeScout system, such as your email and password. You also need to create a database and a user for FreeScout.

    To create a database and a user, you can use RunCloud’s database manager. You can find this in the RunCloud dashboard under the “Database” tab. Follow our tutorial on creating a database to learn more.

    After creating the user, granting them access to a database, and connecting that database to your web application, go back to the FreeScout installation wizard and enter the same details that you used to create the database and the user. Make sure you have selected the MySQL option in the database connection drop-down, and leave the hostname and port as default.

    If everything is okay, you can proceed with the installation by clicking on “Install”. FreeScout will install itself on your server and then show you a success message.

    Final Thoughts

    As you can see, installing FreeScout on Ubuntu using RunCloud is easy and fast. You don’t need to be a Linux expert or spend hours configuring your server. You can leave the hard work to us and focus on your projects.

    RunCloud lets you manage your web apps with a simple and intuitive interface. You can create, deploy, and scale your web apps with just a few clicks. You can also monitor your server performance, secure your web apps, and automate your tasks with RunCloud.

    With RunCloud, you can save time, money, and hassle. You can run any web app on any cloud server provider, such as DigitalOcean, AWS, Google Cloud, and more. You can also enjoy the benefits of RunCloud’s features, such as:

    • One-click SSL certificates
    • Custom domain names
    • Automatic backups
    • Firewall and malware protection
    • Cron job scheduler
    • Git deployment
    • And more!

    Whether you’re a developer, a freelancer, or a business owner, RunCloud is the perfect solution for you. You can manage your web apps with ease and get support from our friendly team anytime you need it. Sign up for RunCloud today and see how it increases your productivity.

  • Everything You Need To Know About wp-config.php File

    Everything You Need To Know About wp-config.php File

    The wp-config file is one of the core WordPress files, which means that understanding how you can navigate it, and make subtle but essential changes, can make a massive difference to your site.

    Responsible for establishing the connections between your WordPress site and the database, the wp-config file is an essential element in determining how smoothly and error-free your site runs.

    In this article, we’ll show you how to navigate your WordPress site’s wp-config file safely, and how to make simple changes that will help improve the security and performance of your site. Let’s get started!

    What Is wp-config.php?

    The wp-config.php file is a configuration file used by WordPress to initialize various settings and options for the website. The file is typically located in the root directory of a WordPress installation and is automatically created when WordPress is first installed. Alternatively, you can create it manually by renaming the wp-config-sample.php file and editing it with your own details.

    Basic Settings in wp-config.php

    The wp-config.php file plays a crucial role in the functioning of a WordPress website, providing the base configuration details, including:

    • WordPress database connection settings: This includes the database name, username, password, and host. Without this information, your WordPress website will not work, and you will get the “error establishing database connection” error.
    • WordPress salts & keys: These are random strings of characters that are used to enhance the security of your WordPress site. They are used to encrypt information stored in cookies, such as user passwords and authentication data.
    • WordPress database table prefix: This is a prefix that is added to each table name in your WordPress database. By default, it is set to `wp_`, but you can change it to anything you want. Changing the table prefix can help prevent SQL injection attacks and conflicts with other applications that use the same database.
    • ABSPATH: This is a constant that defines the absolute path to the WordPress directory on your server. It is used by WordPress to locate files and directories.

    In addition to its core functions, the wp-config.php file also allows for advanced customization of a WordPress website. For example, it can be used to enable debugging and caching options, set up a multi-site installation, and configure environmental variables.

    Advanced Settings in wp-config.php

    The wp-config.php file also allows you to customize various aspects of your WordPress site by defining constants and variables. Some of these are optional, but some are required for certain features or functions to work properly. For example, you can:

    • Enable or disable WordPress debugging mode: This is a mode that displays errors and notices on your website for troubleshooting purposes. By default, it is disabled, but you can enable it by setting the WP_DEBUG constant to true.
    • Increase memory allocated to PHP: This allows you to increase the amount of memory that PHP can use when running your WordPress site. By default, WordPress tries to increase the memory limit to 40MB for single sites and 64MB for multisites, but this may not be enough for some plugins or themes. You can increase the memory limit by defining the WP_MEMORY_LIMIT constant.
    • Disable or enable cron jobs: Cron jobs are scheduled tasks that run at specific intervals on your WordPress site. For example, cron jobs are used to check for updates, publish scheduled posts, and send pingbacks. By default, WordPress uses a pseudo-cron system that runs when a page is loaded. You can disable this system by defining the DISABLE_WP_CRON constant as true.
    • Change file permissions: File permissions are rules that determine who can read, write, or execute files on your server. By default, WordPress uses the file permissions set by your server, but you can override them by defining constants such as FS_CHMOD_FILE, FS_CHMOD_DIR, and FS_METHOD.

    These are just some examples of what you can do with the wp-config.php file. There are many more constants and variables that you can define or modify to customize your WordPress site.

    Where To Find The wp-config.php File

    Locating the wp-config.php file in a WordPress installation is simple. Here are the steps to follow:

    1. Log in to your web hosting account and access the file manager, or use an FTP client.
    2. Locate the root directory of your WordPress installation. This is typically where you installed WordPress, such as public_html or www. RunCloud users can see the path of their web application in the RunCloud dashboard.
    3. Look for the wp-config.php file in the root directory. It should be located alongside other core WordPress files, such as wp-content and wp-includes.
    1. If you can’t find the file in the root directory, check the subdirectories. Sometimes, the wp-config.php file can be located in a subdirectory, such as /wp/.
    2. If you still can’t find the file, try searching for it using the search feature in your file manager or FTP client.

    What Happens If the wp-config.php File Is Missing

    If the wp-config.php file is missing from your WordPress directory, you won’t be able to access your WordPress site or dashboard. Instead, you will be redirected to /wp-admin/setup-config.php.

    This setup page will ask about your database connection details and other basic settings. Once you submit the form, WordPress will create a wp-config.php file for you, and install WordPress.

    Alternatively, you can manually create the wp-config.php file by copying the wp-config-sample.php file from your WordPress directory, renaming it to wp-config.php, and then editing it with your own details.

    If you want to generate nonce keys and salts, refer to our Salts and Keys section.

    Understanding the Structure and Format of the wp-config.php File

    The structure and format of the wp-config.php file are as follows:

    • PHP Tags: wp-config.php is a php file that contains PHP code which defines the configuration settings for WordPress. All PHP files start with <?php and (optionally) end with ?>.
    <?php
    // content
    ?>
    • Comments: These are lines of text that are ignored by PHP and are used for information purposes only. They start with // for single-line comments or /* */ for multi-line comments. For example:
    // MySQL settings 
    /* The name of the database for WordPress */
    • Constants: These are names that represent fixed values that can’t be changed. They’re defined using the define() function, which takes two parameters: the constant name and the constant value. The constant name is usually written in uppercase letters and underscores, and the constant value can be a string, a number, a boolean, or an array. For example:
    define( 'DB_NAME', 'database_name_here' ); // Database name
    define( 'WP_DEBUG', true ); // Debugging mode
    • Variables: These are names that represent values that can be changed. They are assigned using the = operator, and they start with a $ sign. The variable name can be any combination of letters, numbers, and underscores, and the variable value can be any data type supported by PHP. For example:
    $table_prefix = 'wp_'; // Database table prefix
    • Require statements: These are statements that include or require another PHP file to be executed. They use the require_once() function, which takes one parameter: the file path of the file to be included or required. The file path can be absolute or relative to the wp-config.php file. For example:
    require_once( ABSPATH . 'wp-settings.php' ); // WordPress settings file
    require_once( dirname( __FILE__ ) . '/local-config.php' ); // Local configuration file

    Editing The wp-config.php File

    It’s important to edit the wp-config.php carefully to avoid causing any issues. Here are the steps to do this safely:

    1. Back up your website: Before making any changes to your site, it’s essential to create a backup of your website in case something goes wrong. You can use a backup plugin or ask your hosting provider for backup options.
      If you don’t have a backup plugin installed on your site, you can simply copy the old file using the cp command and change the name, so it is abundantly clear which file is the old one, such as wp-config-BACKUP.
    1. Open the file in a text editor: After backing up the wp-config.php file, open it in a text editor, such as VS Code, Sublime Text, or nano.
    2. Make your changes: Once a file is open in a text editor, be cautious, as a small mistake can cause significant problems with your site.
    3. Save the file: Once you have made your changes, save the file and close the text editor.
    4. Test your site: After saving the changes, you should check your website to ensure it is functioning correctly. You can revert to the backup you created if there are any issues.

    It’s important to remember that even small changes to the wp-config.php file can have a significant impact on your website, so be careful when making edits. If you’re not familiar with editing files, or are unsure about a change, it’s best to consult a developer or seek support from your hosting provider.

    General Settings in wp-config.php File

    Here are the most important settings that should be configured in the wp-config.php file relating to the functionality and security of your site:

    Database Connection Settings

    These settings define the connection to your database, and store information such as the database name, username, password, and host.

    The database connection settings must match the information for your database, or you will receive an error message when trying to access your site.

    You can define these settings as follows:

    editing wp-config.php file

    Security Keys and Salts

    These keys are random strings of data that enhance the security of your site by adding an extra layer of protection against hacking attempts. They are used to encrypt information stored in cookies, such as user passwords and authentication data.

    By changing these keys and salts periodically, you can invalidate any existing cookies and force users to log in again. This can help prevent cookie hijacking attacks and improve security.

    salts in wp-config.php file

    You can generate new security keys and salts in several different ways:

    • By visiting https://api.wordpress.org/secret-key/1.1/salt/ and copying the generated keys and salts. Then, you can paste them into your wp-config.php file, replacing the existing ones.
    • You can also use a WP CLI command to generate new security keys and salts without visiting any website. To do so, you need to:
      • Connect to your server via SSH or use a control panel.
      • Navigate to your WordPress installation directory with cd /path/to/wordpress.
      • Run the following command: wp config shuffle-salts.
    • You can also use a plugin to generate new security keys and salts without editing any file. One such plugin is Salt Shaker, which allows you to either change the keys and salts manually, or automatically on a schedule.

    WP_CACHE Setting

    This setting controls whether caching is enabled in WordPress. Caching can improve the performance of a WordPress site by storing frequently accessed data in a cache memory, which is significantly faster than re-processing it every time the page is loaded.

    However, caching can also serve stale or outdated data, which can lead to an inconsistent user experience. Therefore, you should set this value carefully depending on your content and caching plugin. Read our deep dive on WordPress object caching to learn more. 

    By default, WP_CACHE is not defined, which means caching is disabled in WordPress. You can set it to true to enable caching in WordPress, which will use the caching plugin that you have installed and activated on your site. 

    define( 'WP_CACHE', true ); // Enable caching in WordPress

    File Permissions Setting

    This flag determines how WordPress interacts with the file system of your web server. The file system is where your WordPress files and folders are stored and accessed.

    The default value of FS_METHOD is “direct”, which means WordPress accesses the file system directly without using any protocol.

    This is usually sufficient for most hosting environments, but in some cases, you may need to change this value to resolve file permission issues. The possible values of FS_METHOD are:

    • direct: WordPress accesses the file system directly
    • ssh2: WordPress uses the Secure Shell (SSH) protocol to access the file system
    • ftpext: WordPress uses the File Transfer Protocol (FTP) to access the file system
    • ftpsockets: WordPress uses the FTP Secure (FTPS) protocol to access the file system

    For example, you can define this setting as follows:

    define( 'FS_METHOD', 'ssh2' ); // Use SSH to access the file system

    Multi-site Setup

    A multi-site installation allows you to create a network of multiple sites using a single WordPress installation. This can be useful if you want to run multiple websites with different themes and plugins, or if you want to manage multiple sites from a single dashboard. You can read more about WordPress multisite in our blog post.

    You can enable multi-site by defining the WP_ALLOW_MULTISITE constant in your wp-config.php file. By default, this flag is not defined, which means multi-site functionality is disabled in WordPress. You can define this setting as follows:

    define( 'WP_ALLOW_MULTISITE', true ); // Enable multi-site functionality in WordPress

    After defining this setting, you need to log in to your WordPress dashboard and navigate to the “Tools” menu. You should see the “NetworkSetup” option, which will guide you through the process of creating and configuring your network of sites.

    Disabling Automatic Updates

    You can edit your wp-config.php file to disable automatic updates for WordPress core releases, translations, themes, and plugins. While these updates can help keep your site secure and up-to-date, they can also cause compatibility issues – or break your site if something goes wrong.

    Moreover, if you have customized your themes or plugins, automatic updates can overwrite your changes and erase your work.

    // Disable all automatic updates
    define( 'AUTOMATIC_UPDATER_DISABLED', true );
    // Disable automatic updates for core
    define( 'WP_AUTO_UPDATE_CORE', false );
    // Disable automatic updates for themes
    add_filter( 'auto_update_theme', '__return_false' );
    // Disable automatic updates for plugins
    add_filter( 'auto_update_plugin', '__return_false' );

    These lines will disable all types of automatic updates for your WordPress site. If you want to enable only specific types of automatic updates, you can modify the corresponding lines. For example, if you want to enable automatic updates for minor core releases only, you can change WP_AUTO_UPDATE_CORE to minor.

    Reading Environmental Variables

    Environmental variables are a way to store configuration data that can be easily managed and changed without affecting the codebase. This is particularly useful in WordPress, where you might want to use different settings in different environments.

    These variables are set outside of the WordPress code, usually in the server configuration or the .env file – very different from WordPress constants. WordPress constants are defined inside the WordPress code, usually in the wp-config.php file or a custom plugin.

    Environment variables can be different for different environments (such as development, staging, or production), while WordPress constants are usually the same for all environments (unless they are conditionally defined).

    One reason why someone would load their database credentials from environment variables is to keep them secure and out of the version control system. This way, they can avoid exposing sensitive information to unauthorized users or hackers.

    Another reason is to make it easier to switch between different environments without having to edit either the wp-config.php file or the database.

    For example, if you use a .env file for storing your database credentials, you can simply change the values in that file when you move your site from development to production, without affecting the rest of your WordPress code.

    To retrieve the environmental variables in wp-config.php, you can use the PHP function getenv(). For example, if you have an environmental variable named “DB_PASSWORD”, you can retrieve it in wp-config.php using the following code in wp-config.php:

    define( 'DB_PASSWORD', getenv('DB_PASSWORD'));

    It’s essential to remember that environmental variables should be stored securely, and never included in either version control or shared publicly, as they often contain sensitive information.

    Configure WordPress Environment

    The WP_ENVIRONMENT_TYPE variable controls the environment type for a WordPress site. The possible values are local, development, staging, and production. The value of the environment type can affect how WordPress behaves, and how plugins and themes handle specific functionality.

    There are two ways to set the WP_ENVIRONMENT_TYPE variable for your WordPress site:

    • Using a PHP environment variable: This can be done using various methods, depending on your server configuration and hosting provider.
    • Using a WordPress constant: To do this, you need to add the following line to your wp-config.php file:
    define( 'WP_ENVIRONMENT_TYPE', 'production' );

    Once you have set the WP_ENVIRONMENT_TYPE variable for your WordPress site, you can use it in various ways to customize and optimize your site’s behavior and functionality. For example, you can use it to enable or disable debugging features, automatic updates, caching, specific plugins or themes, and more.

    To use the WP_ENVIRONMENT_TYPE variable in your code, you can use the wp_get_environment_type() function, which returns the current environment type as a string. For example, you can write something like this:

    switch ( wp_get_environment_type() ) {
      case 'local':
        // do something for local sites
        break;
      case 'development':
        // do something for development sites
        break;
      case 'staging':
        // do something for staging sites
        break;
      case 'production':
      default:
        // do something for production sites or any other sites
        break;
    }

    This way, you can conditionally execute different code blocks depending on the environment type of your WordPress site.

    Modify the Location of WordPress Folders

    Change the content folder

    WordPress stores all your themes, plugins, uploads, and other files in the wp-content folder by default. You can change this folder name and location by defining the WP_CONTENT_DIR and WP_CONTENT_URL constants in your wp-config.php file. Here is an example:

    define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/assets' ); // Change content folder name and location
    define( 'WP_CONTENT_URL', 'https://example.com/assets' ); // Change content folder URL

    Change the plugins folder

    WordPress stores all your plugins in the wp-content/plugins folder by default. You can change this folder name and location by defining the WP_PLUGIN_DIR and WP_PLUGIN_URL constants in your wp-config.php file. 

    define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/assets/extensions' ); // Change plugins folder name and location
    define( 'WP_PLUGIN_URL', 'https://example.com/assets/extensions' ); // Change plugins folder URL

    Change the uploads folder

    WordPress stores all your media files in the wp-content/uploads folder by default. You can change this folder name and location by defining the UPLOADS constant in your wp-config.php file. For example, to rename the uploads folder to ‘media’ and move it to the assets folder, you can add this line:

    define( 'UPLOADS', 'assets/media' ); // Change uploads folder name and location

    Set a Custom Default Theme

    WordPress uses the latest default theme (such as Twenty Twenty-One) as the fallback theme when no other theme is available or active. You can define a custom default theme by using the WP_DEFAULT_THEME constant in your wp-config.php file. For example, to use a theme named ‘MyTheme’ as the default theme, you can add this line:

    define( 'WP_DEFAULT_THEME', 'mytheme' ); // Use MyTheme as the default theme

    Configuring Developer Settings

    The wp-config.php file also allows you to configure some developer settings that can help you debug and optimize your WordPress site. Some of the most useful developer settings are:

    Enabling Debugging

    You can turn on the WP_DEBUG constant to display PHP errors and notices on your site. This can help you identify and fix any coding issues or compatibility problems.

    By default, WP_DEBUG is set to false, which means the debugging mode is off. You can set it to true in order to turn on debugging mode. This will log errors and warnings to a file, and display them on your site.

    You can also set WP_DEBUG_LOG to true to specify that debugging information should be logged to a file, and set WP_DEBUG_DISPLAY to false to hide debugging information from being displayed on your site. For example, you can define these flags as follows:

    define( 'WP_DEBUG', true ); // Turn on debugging mode in WordPress
    define( 'WP_DEBUG_LOG', true ); // Log debugging information to a file
    define( 'WP_DEBUG_DISPLAY', false ); // Hide debugging information from being displayed on the site
    define('SCRIPT_DEBUG', true); //loads the development (non-minified) versions of all scripts and CSS, and disables compression and concatenation.

    Controlling Script Concatenation and Minification

    WordPress concatenates (combines) and minifies (reduces) some of its core scripts and stylesheets to improve performance and reduce HTTP requests. However, this can sometimes cause issues with some plugins or themes that rely on specific scripts or styles. You can disable script concatenation and minification by adding the following line to your wp-config.php file:

    define( 'CONCATENATE_SCRIPTS', true );
    define('COMPRESS_SCRIPTS', true); 
    define('COMPRESS_CSS', true); 
    define('ENFORCE_GZIP', true); //forces gzip for compression instead of deflate

    Logging SQL queries

    WordPress uses SQL queries to interact with the database and fetch data for your site. Sometimes, you may want to see what queries are being executed and how long they take. This can help you troubleshoot any database issues or optimize your site for speed. You can log SQL queries by adding the following lines to your wp-config.php file:

    define( 'SAVEQUERIES', true );
    global $wpdb;
    print_r( $wpdb->queries );

    Use Different Table Names for Users and Usermeta Tables

    Change the users table name

    WordPress uses the wp_users table to store user information by default. You can change this table name by defining the CUSTOM_USER_TABLE constant in your wp-config.php file. For example, to use a table named my_users instead of wp_users, you can add this line:

    define( 'CUSTOM_USER_TABLE', $table_prefix . 'my_users' ); // Use my_users instead of wp_users

    Change the usermeta table name

    WordPress uses the wp_usermeta table to store user metadata by default. You can change this table name by defining the CUSTOM_USER_META_TABLE constant in your wp-config.php file. For example, to use a table named my_usermeta instead of wp_usermeta, you can add this line:

    define( 'CUSTOM_USER_META_TABLE', $table_prefix . 'my_usermeta' ); // Use my_usermeta instead of wp_usermeta

    Repairing and Optimizing The Database

    Sometimes, your WordPress database may get corrupted or damaged due to various reasons, such as server errors, hacking attempts, plugin conflicts, or power failures. This can cause your site to malfunction or display errors.

    To fix your database, you can use the WP_ALLOW_REPAIR constant in your wp-config.php file. This will enable a database repair and optimization feature that you can access by visiting this URL: https://example.com/wp-admin/maint/repair.php

    To enable this feature, add the following line to your wp-config.php file:

    define( 'WP_ALLOW_REPAIR', true );

    After visiting the URL, you can choose to either repair your database, or repair and optimize your database.

    Once the process is complete, you should remove the WP_ALLOW_REPAIR line from your wp-config.php file to prevent anyone else from accessing the feature.

    Disabling Table Updates

    WordPress updates its database tables whenever a new version of WordPress is released, or when a plugin or theme requires a database change. This ensures that your site is compatible with the latest features and security patches.

    However, sometimes you may want to disable table updates for various reasons, such as:

    • You have a large site with many tables, and updating them may take a long time or cause downtime.
    • You have a staging or development site that mirrors your live site and you don’t want to update the tables until you are ready to deploy the changes.
    • You have a specific scenario where updating the tables may break something on your site, or cause conflicts with other plugins or themes.

    To disable table updates, you can add the following line to your wp-config.php file:

    define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );

    This will prevent WordPress from updating any of the global tables, such as wp_users, wp_usermeta, wp_blogs, etc. However, this may also prevent some plugins or themes from working properly, so use this option with caution – and only when necessary.

    Database Collation

    WordPress does not create the database on installation. This is important to know because all tables within a database will inherit their charset and collation from the database setting. So you should ensure that the database’s charset and collation is properly set before WordPress is installed.

    The default charset is ‘utf8’ and its collation is ‘utf8_general_ci’, which means case-insensitive comparison using the general rules of Unicode.

    To change the database collation in wp-config.php you can simply modify the value of the DB_COLLATE constant to match your desired collation. For example, if you want to use ‘utf8mb4_unicode_ci’, you can write:

    define( 'DB_COLLATE', 'utf8mb4_unicode_ci' );

    Security and Performance

    The wp-config.php file is not only a configuration file, but also a security file. It contains sensitive information that can compromise your WordPress site if exposed to unauthorized users or malicious attacks. Therefore, it is essential to protect the wp-config.php file from visitors and hackers, and to optimize it for better security and performance.

    Protecting Access to wp-config.php by Visitors

    If an attacker gains access to this file, they can compromise your site and database. Therefore, you need to protect the wp-config.php file from visitors by using one of the following methods:

    • Moving the wp-config.php file: One of the simplest ways to protect the wp-config.php file from visitors is to move it to a higher level, outside the public directory of your WordPress installation. This way, the file will not be accessible via a web browser, and only WordPress will be able to locate it. WordPress will automatically look for the file in the parent directory if it is not found in the root directory.
    • Block access to the file: Another way to protect the wp-config.php file from visitors is to use directives in .htaccess or Nginx configuration files. These are files that control how your server handles requests and responses. By adding some rules to these files, you can deny access to the wp-config.php file. If someone tries to access it, they will get a 403 Forbidden error.

    Disabling File Editors

    Another way to improve the security and performance of your WordPress site is to disable the file editors. These are the theme editor and the plugin editor that allow you to edit the code of your themes and plugins from within the WordPress dashboard.

    While these editors can be useful for quick changes, they can also pose both a security risk and a performance issue. If someone gains access to your WordPress dashboard, they can use the file editors to inject malicious code or delete important files. Moreover, if you make a mistake while editing the code, you can break your site or introduce vulnerabilities.

    To disable the file editors, you need to add the following line in your wp-config. php file:

    define( 'DISALLOW_FILE_EDIT', true );

    This line will remove the theme editor and the plugin editor from the WordPress dashboard. If you want to edit your themes or plugins, you will need to use an FTP client or a file manager.

    Blocking External HTTP Requests

    Another way to improve the security and performance of your WordPress site is to block external HTTP requests. These are requests that WordPress makes to other domains or servers for various purposes, such as checking for updates, fetching feeds, or loading scripts.

    While some of these requests are necessary and beneficial, some of them may be unwanted, unnecessary, or malicious. Blocking external HTTP requests can help prevent unauthorized access, reduce bandwidth usage, and speed up your site.

    To block external HTTP requests, you need to add the following line to your config file:

    define( 'WP_HTTP_BLOCK_EXTERNAL', true );

    This line will block all external HTTP requests made by WordPress, except for localhost and your own domain. This will make your site more secure and faster.

    However, blocking all external HTTP requests may also break some features or functions of your WordPress site that rely on them. For example, you may not be able to check for updates, install themes or plugins, or use third-party services.

    To allow some external HTTP requests, you can use another constant called WP_ACCESSIBLE_HOSTS. This constant allows you to specify a comma-separated list of domains or hosts that are allowed to make external HTTP requests. You can also use wildcards to allow subdomains. For example:

    define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );

    This line will allow external HTTP requests to api.wordpress.org and any subdomain of github.com. You can add or remove domains or hosts as per your needs.

    Forcing SSL for Login Pages and the Dashboard

    Although virtually all websites these days use HTTPS, some websites still might be serving content on HTTP for legacy reasons. You can improve the security and performance of your WordPress site by forcing SSL for login pages and the dashboard.

    This prevents anyone from intercepting or tampering with your data, such as usernames, passwords, cookies, and other sensitive information. SSL also improves the performance of your site by enabling HTTP/2 – a faster and more efficient version of HTTP.

    The following line of code will force SSL for login pages and the dashboard:

    fine( 'FORCE_SSL_ADMIN', true );

    Note: You’ll need to obtain an SSL certificate for your domain name, install it, and activate the SSL certificate on your server before enabling this setting. You may need to contact your hosting provider for assistance with this step.

    Optimize WordPress Performance via wp-config.php

    Empty the trash more frequently

    WordPress moves deleted posts, pages, comments, and other items to the trash, where they remain for 30 days by default. You can change this duration by defining the EMPTY_TRASH_DAYS constant in your wp-config.php file.

    For example, to empty the trash every 7 days, you can add this line:

    define( 'EMPTY_TRASH_DAYS', 7 ); // Empty trash every 7 days

    Disable revisions

    WordPress saves a copy of every post or page revision, which can increase the size of your database and slow down your site. You can disable revisions completely by defining the WP_POST_REVISIONS constant in your wp-config.php file. For example, to disable revisions, you can add either of these lines:

    define( 'WP_POST_REVISIONS', false ); // Disable revisions
    define( 'WP_POST_REVISIONS', 5 ); // Limit revisions to 5

    Handling memory limitations

    WordPress requires a certain amount of memory to run smoothly and efficiently. The default memory limit for WordPress is 40 MB for single sites, and 64 MB for Multisite installations. However, sometimes you may need more memory for your site, especially if you have a high number of plugins or themes installed, have complex functionality, or high traffic.

    To increase the memory limit for WordPress, you can use the WP_MEMORY_LIMIT constant in your wp-config.php file. For example, to increase the memory limit to 128 MB, add the following line:

    define( 'WP_MEMORY_LIMIT', '128M' );

    You can also use the WP_MAX_MEMORY_LIMIT constant to set the maximum memory limit that WordPress can use for intensive tasks, such as image editing or cron jobs. For example, to set the maximum memory limit to 256 MB, add the following line:

    define( 'WP_MAX_MEMORY_LIMIT', '256M' );

    Note that these constants may not work if your server has a lower memory limit set by PHP or Apache. In that case, you may need to contact your hosting provider, or edit your php.ini or .htaccess files to increase the server memory limit.

    Change the autosave interval

    WordPress autosaves your posts and pages every 60 seconds by default, which can be annoying or helpful, depending on your preference. You can change the autosave interval by defining the AUTOSAVE_INTERVAL constant in your wp-config.php file.

    For example, to change the autosave interval to 120 seconds, you can add this line:

    define( 'AUTOSAVE_INTERVAL', 120 ); // Change autosave interval to 120 seconds

    The WP Loading Process – When wp-config Loads (and What’s Already Loaded)

    The wp-config.php file is one of the first files that WordPress loads when a page is requested. It’s loaded even before WordPress initializes its core functions, classes, and hooks.

    The WP loading process is as follows:

    1. When a page is requested, WordPress looks for the .htaccess file in the root directory of your WordPress installation. This file contains rules that rewrite URLs and direct them to the index.php file.
    2. The index.php file requires another file called wp-blog-header.php.
    3. The wp-blog-header.php file requires another file called wp-load.php.
    4. The wp-load.php file is a bootstrap file that loads the WordPress environment and template. It looks for the wp-config.php file in two locations:
      • The root folder of your WordPress installation.
      • One directory above the root folder, if the file is not found in the root folder.
    5. If wp-config.php is missing, it starts a fresh installation.

    To learn more about this topic, we recommend two articles – WordPress loading sequence and How WordPress Core Loads.

    After Action Report – Managing wp-config.php

    The wp-config.php file is a vital part of a WordPress website, and must be appropriately configured for the website to function correctly. It’s essential to understand how to locate and edit the file, and troubleshoot any issues that may arise.

    With RunCloud, you can easily set up and manage your servers, including configuring your wp-config.php file, with just a few clicks.

    RunCloud also offers a variety of features, such as automatic backups, monitoring, and scaling options to help ensure your site runs smoothly – all through a secure and user-friendly management panel.Don’t waste any more time on complicated server management – sign up for RunCloud today!

  • Scaling RAM & CPU Cores – How They Affect WordPress Performance

    Scaling RAM & CPU Cores – How They Affect WordPress Performance

    Did you know that a one-second delay in page load time can reduce conversions by 7%?

    Or, that Google penalizes slow sites in its search rankings?

    These are just some of the consequences of having a poorly performing WordPress site. And one of the main factors that affects your site’s performance is the amount of RAM and number of CPU cores that your hosting plan provides.

    But what are RAM and CPU cores, and how do they relate to WordPress hosting?

    How can you tell if your site needs more or less of them? And how can you scale them up or down to optimize your site’s performance?

    In this article, we’ll answer all of these questions, and more. We will explain what RAM and CPU cores are, how they work, and why they matter for your WordPress site. We will also give you some examples of WordPress sites that require high RAM and CPU resources, and how to scale them accordingly. Finally, we will share some tips and best practices to improve your site’s performance, and avoid wasting resources.

    If you want to learn how to make your WordPress site faster, smoother, and more reliable, read on!

    Why Do Sites Need RAM and CPU?

    RAM and CPU are the main components of your hosting server that determine how fast and reliable your WordPress site is. Let’s see what they do and why they matter.

    What is RAM?

    RAM stands for Random Access Memory, and is the temporary storage space that your WordPress site uses to load and process data. Every time someone visits your site, WordPress needs to access the database, load the files, and execute the code. All these operations require RAM to store the data temporarily.

    RAM is typically measured in Megabytes and Gigabytes. Most cloud providers allow you to configure the amount of RAM available on your server. The more RAM you have, the more data your site can handle at once. This means your site can load faster, handle more traffic, and run more plugins – without crashing or slowing down.

    What is a CPU?

    CPU stands for Central Processing Unit, and is the “brain” of your WordPress site that executes commands and calculations. Every time someone visits your site, WordPress needs to perform some logic and calculations to generate the output. For example, it needs to check the user’s permissions, apply the theme’s settings, run the plugins’ functions, and so on. All these operations require a CPU to process the commands.

    The CPU is measured in the number of cores. The more CPU cores you have, the more commands your site can execute at once. This means your site can perform faster, handle more complex tasks, and run more plugins without errors or delays.

    As you can see, both RAM and CPU are essential for your WordPress site to function properly.

    However, they also have limits.

    The more RAM and CPU cores you have, the more processes you can run simultaneously, and the faster your site can respond to visitors. If your site receives a lot of traffic or runs complex tasks, it might need more RAM and CPU resources than are available on your current hosting plan. This can result in slow loading times, errors, or even crashes.

    That’s why you need to choose a hosting plan that provides enough RAM and CPU resources for your WordPress site. You also need to monitor your site’s performance and usage regularly, and scale your resources up or down as needed. In this way, you can ensure that your WordPress site runs smoothly and efficiently at all times.

    Which Sites Benefit From More RAM and CPU?

    Not all WordPress sites need the same amount of RAM and CPU resources. Some sites are more demanding and complex than others, and they can benefit from having more RAM and CPU resources to run smoothly and efficiently.

    Some examples of WordPress sites that require high RAM and CPU resources are:

    • E-commerce sites that handle a lot of transactions and inventory. These sites need to load and process a lot of data, such as product details, prices, images, reviews, cart items, payment methods, and so on. They also need to handle a lot of user requests, such as adding items to the cart, checking out, updating orders, etc. All these operations require a lot of server resources to avoid slow loading times, errors, or crashes.
    • Membership sites that have a lot of users and content. These sites need to store and manage a lot of user data, such as profiles, preferences, subscriptions, activities, etc. They also need to load and display a lot of content, such as posts, pages, videos, podcasts, courses, etc. A large amount of traffic will put additional strain on a server’s resources.
    • Media sites that stream or download large files. These sites need to handle a lot of bandwidth and storage for the media files, such as images, audio, video, etc. They also need to encode and decode the files for different formats and devices. All these operations require a lot of RAM and CPU resources to deliver high-quality media without buffering, lagging, or breaking.
    • Multisite networks that run multiple WordPress sites on one server. These sites need to share the same server resources for all of the sub-sites in the network. This means that each sub-site needs to have enough RAM and CPU resources to function properly without affecting the other sub-sites. Running multiple sites requires a large amount of server resources.
    • If your site experiences a sudden surge in traffic, such as during a launch, promotion, or viral event, you might need to scale up your RAM and CPU resources to handle the increased load. In this way, you can avoid slow loading times, errors, or crashes that can frustrate your users and hurt your conversions.
    • If your site runs complex plugins or tasks, you might need to scale up your RAM and CPU resources to run them smoothly and efficiently. In this way, you can avoid performance issues, bugs, or conflicts that can affect your site’s functionality and user experience.

    Measuring Performance Gains

    It’s widely believed that “a bigger server will obviously outperform a smaller server”.

    To put this to test, we created 3 identical websites on 3 fresh servers using WordPress 6.2. All of the servers had identical configurations – except the CPU and RAM.

    We ran load testing benchmarks using Grafana k6 to stress test the performance of our website, and measure the impact in 95 percentile response times. Since the purpose of this test is to put strain on CPU and RAM, we didn’t use any optimization techniques such as caching that are used in real world applications.

    1v CPU 2 GB RAM

    Our smallest server used the cheapest hosting plan offered by the cloud provider. It consisted of only 1 virtual CPU and 2 GB of RAM. Despite this, it was able to serve nearly 20 requests per second and had a p95 response time of 815ms. This is not bad considering it only costs <$5 to run. Most users will be able to afford it and will be satisfied with it – as long as the site doesn’t get too much traffic.

    2v CPU and 8 GB RAM

    Our second server was moderately priced, this one consisted of 2 virtual CPU cores and 8GB of RAM. This server size is probably unnecessary if you’re running a hobby site, but if you use your site for critical business transactions, then you should consider this.

    Just by slightly increasing the resources, we were able to see a massive jump in the performance. The server completed nearly 36 requests every second with a p95 response time of 104ms. These numbers suggest that our server was limited by the number of resources during our first test. Let’s crank it up further and see if the numbers scale proportionally.

    8v CPU 32 GB RAM

    Our third server was the most expensive of the three, it contained 8 virtual CPUs and a whopping 32 GB of RAM. However, when we look at the numbers, they tell a different story. The number of requests per second metric saw only a minor bump from 36 to 39; furthermore, the p95 response time metric didn’t improve.

    Trade Offs to Consider While Scaling RAM and CPU

    You also need to be aware of the potential drawbacks or challenges of scaling RAM and CPU cores.

    Unexpected Crashes

    Scaling RAM and CPU cores might cause some unexpected issues or conflicts that can break your site.

    For example, you might encounter compatibility problems with some plugins or themes that are not optimized for the new resources. Or you might face some server errors or configuration issues that prevent your site from loading properly.

    These issues or conflicts can make your site inaccessible or unusable until you fix them, or revert to the previous state.

    Planned Downtime

    Furthermore, many hosting providers require you to shut down your server before you can increase or decrease your server’s RAM and CPU.

    This means that your site will be offline for the duration of the upgrade. Although most providers will be able to scale up your server within a few minutes, this does vary from vendor to vendor, and depends on availability.

    Increase in Hosting Costs

    Finally, scaling RAM and CPU cores can also affect the price of your hosting plan. Some providers and plans might offer flexible or scalable pricing that adjusts to your resource usage. Others might charge you a fixed or flat rate regardless of your resource usage. And others might have different tiers or levels of pricing that correspond to different amounts of resources.

    You need to weigh the costs and benefits of scaling, and find the best balance for your site’s budget and needs.

    You need to consider how much scaling will improve your site’s performance and user experience, and how much it will increase your hosting expenses. You should also compare different providers and plans to find the one that offers the best value and quality for your site.

    More Resources Might Not Benefit the Site

    Simply adding more RAM and CPU cores does not guarantee better performance if there are other limiting factors such as network speed, disk speed, or PHP workers.

    PHP workers are processes that handle PHP requests on your WordPress site. Some hosting providers limit the number of PHP workers available on your server. If you have too few PHP workers, your site may become slow or unresponsive when there are many concurrent visitors or complex tasks. If you have too many PHP workers, they may consume too much RAM and CPU resources, and cause your server to crash.

    Final Thoughts – Thinking Beyond RAM and CPU

    It’s clear that you can’t keep scaling up the hardware and expect proportional increase in performance.

    Throwing money at the problem only works up to a point.

    Beyond that, you need to fine tune your application to consume fewer resources, and find the optimal balance between RAM, CPU cores, and PHP workers for your WordPress site based on your traffic, content, and plugins. There are several ways to do this:

    • You can use caching, a technique that can improve your WordPress performance by storing frequently accessed data in memory or on disk, and serving it faster to visitors without invoking PHP workers.

    There are different types of caching such as page caching, object caching, edge caching, etc. You need to choose the right caching solution for your WordPress site, depending on your needs and preferences.

    If you’re tired of managing your own servers, you might want to check out RunCloud (yep, that’s us!).

    RunCloud is built for developers that want to focus on shipping great work, not on managing their infrastructure. Experience what a painless server configuration feels like – get started with RunCloud today, and get up and running in minutes.