One place for hosting & domains

      Troubleshooting

      How To Optimize a WordPress Installation Before Troubleshooting



      Part of the Series:
      Common WordPress Errors

      This tutorial series explains how to troubleshoot and fix common errors that you may encounter when deploying, maintaining, and updating your WordPress installation.

      Each tutorial in this series includes descriptions of common deployment, maintenance, or update errors, and explores ways to fix and optimize your installation to scale.

      Introduction

      WordPress is a robust Content Management System (CMS) that provides blog and site infrastructure, creation, and publishing tools. While WordPress is a well-maintained, open source CMS, you may sometimes encounter issues or errors that will prevent you from having access to common functionalities.

      In this tutorial, you’ll learn how to perform steps to ward against common WordPress errors in a way that also optimizes your site to prevent those errors from occurring in the future.

      Step 1 — Creating a Backup of Your Site

      Before you begin any troubleshooting process, it’s wise to back up your site. Creating backups of your site, whether manually or by using a plugin, allows you to restore your WordPress installation in the event of an error. A backup also serves to protect your WordPress site against security threats, data loss, and more.

      Learn How To Back Up Your WordPress Site to Object Storage with our tutorial, or explore WordPress Backup Plugins to automate the backup process.

      Step 2 — Making Sure your Cache is Clear

      A cache is a temporary storage space that allows browsers and programs to take a snapshot of your site and store temporary files and data, to load your site faster and increase performance.

      While caching does generally give a performance boost to site load times and improves user experience, sometimes errors with visual elements may be a result of a cached version of your site being served. Clearing your browser cache as well as your WordPress cache typically solves issues with older or cached versions of your site being shown.

      This list shares step-by-step information to clear your browser cache on any browser, and there are a number of site caching plugins available that allow you to clear and maintain WordPress cache size, in order to optimize your site’s appearance and performance.

      Step 3 — Auditing Your Plugins

      Plugins are third-party software added to WordPress installations to extend functionality. Even though these extensions provide helpful and convenient features, they can sometimes conflict with each other and cause your site to experience issues in performance, speed, and security.

      To audit your plugins and potentially troubleshoot an error, start by ensuring that each of your plugins are updated to its most recent version. Next, you can also deactivate all plugins and reactivate them one-by-one.

      While inside of your WordPress site’s admin panel, click Plugins, then All Plugins. Within your list of plugins, click the box to Select All, then click Deactivate from the dropdown above the checkbox. Click Apply to deactivate all plugins.Then, select one plugin at a time and click Activate to reactivate each of them while monitoring your website to identify any issues .

      Conclusion

      This tutorial highlighted three steps that you can take to prevent your WordPress site from experiencing common errors, and to maintain the health of your WordPress installation.

      For more information on optimizing your WordPress installation on Ubuntu, visit our tutorial, How to Optimize WordPress on Ubuntu 20.04.



      Source link

      Troubleshooting DNS Records


      Updated by Linode

      Written by Linode

      Having problems with your DNS records? This guide to help get your DNS settings back on track. Follow these tips to troubleshoot DNS issues.

      Before You Begin

      The Domains section of the Linode Cloud Manager is a comprehensive DNS management interface that allows you to add DNS records for all of your domain names. For an introduction to DNS Manager including setting up DNS records, see the DNS Manager guide.

      Note

      Linode’s DNS service employs Cloudflare to provide denial of service (DDoS) mitigation, load balancing, and increased geographic distribution for our name servers. These factors make our service reliable, fast, and a great choice for your DNS needs.

      Note

      To use the Linode DNS Manager to serve your domains, you must have an active Linode on your account. If you remove all active Linodes, your domains will no longer be served.

      Wait for Propagation

      DNS updates will take effect, or propagate, within the time period set by your zone file’s TTL. If you’ve just made a DNS change and aren’t seeing it reflected yet, the new information may not be available for up to 48 hours.

      While you can’t control DNS caching at every point on the Internet, you do have control over your web browser. Try holding down the Shift key or the Control key (depending on your browser) while you refresh the page to bypass your browser’s cache of the old DNS data. You can also try bringing up your site in an alternate browser or editing your hosts file to preview your website without DNS.

      Set the Time To Live or TTL

      In the context of DNS, Time to Live (TTL) tells internet servers how long to cache particular DNS entries. The default TTL for Linode domain zone files is 24 hours. This is fine for most situations because most people don’t update their IP addresses often.

      However, there are times when you’ll want the TTL to be as low as possible. For instance, when you make a DNS change, you’ll want that change to propagate quickly. Otherwise, some people will see the new site right away, and others (who had the old data cached) will still be visiting the website at your old server. Long caching times can be even more problematic when it comes to email, because some messages will be sent to the new server and some to the old one.

      The solution is to lower your TTL before making a DNS change. You’ll want to lower the TTL first, before making any other DNS changes. Here’s a general overview of what should happen during a smooth DNS update:

      Note

      TTL is always written out in seconds, so 24 hours = 86400 seconds.

      1. Check the TTL value for the DNS record you will be updating. Typically, this will be 24 or 48 hours.
      2. Update the relevant DNS records 48 to 96 hours in advance (for a 24-48 hour record), taking into account any intermediate DNS servers. Lower the TTL to five minutes (300 seconds, or the lowest allowed value). Do not make any other changes at this time.
      3. Wait out the original 48 to 96 hours.
      4. Visit your domain’s DNS records in the Linode Cloud Manager again to update your IP address and anything else needed.
      5. The DNS changes should propagate within 30 minutes.

      Find Current DNS Information

      Sometimes you may need to find the current DNS information for a domain. There are two great tools for doing this:

      • dig: Look up individual DNS entries. For example, you can find the IP address where your domain resolves.

      • whois: Find your registrar and nameserver information for your domain.

      If you’re using a computer that runs macOS or Linux, you can use these tools from the command line. To find your domain’s IP (the primary A record), run:

      dig example.com
      

      Look in the answer section of the output to locate your IP address. You can also query for other types of records. For example, to see the mail records for a domain, run:

      dig mx example.com
      

      This returns all of your domain’s MX records.

      To find your domain’s registrar and nameserver information, run:

      whois example.com
      

      This generates a large amount of information about the domain. The basic information you need will be near the top of the output, so you might have to scroll back to see it.

      For a web-based tool, you can also use kloth.net for dig requests and whois.net for WHOIS requests. Note that since you’re running these lookups from a third-party website, the information they find is not necessarily what your local computer has cached. There should be a difference only if you’ve made recent changes to your DNS information.

      For more information and examples on how to use dig, see our Use dig to Perform Manual DNS Queries guide.

      Name Resolution Failures

      If you have DNSSEC enabled at your domain’s registrar it will cause name resolution failures such as NXDOMAIN when an attempt is made to access the DNS. This is because the Linode DNS Manager does not support DNSSEC at this time.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      Troubleshooting Linode Longview


      Updated by Linode

      Written by Linode

      This guide discusses basic troubleshooting steps to help you diagnose and resolve any issues you may encounter while using Longview. If you’re experiencing problems with the Longview client, follow the steps outlined in this guide to help determine the cause.

      Basic Diagnostics

      1. Ensure that your system is fully updated.

        Note

        Longview requires Perl 5.8 or later.

      2. Verify that the Longview client is running. Use the command that is appropriate for your distribution’s initialization system:

        CentOS, Debian, and Ubuntu

        sudo systemctl status longview   # For distributions with systemd.
        

        Other Distributions

        sudo service longview status     # For distributions without systemd.
        

        If the Longview client is not running, start it with the command appropriate for your distribution’s initialization system:

        CentOS, Debian, and Ubuntu

        sudo systemctl start longview
        

        Other Distributions

        sudo service longview start
        

        If the service fails to start, check Longview’s log for errors. The log file is located in /var/log/linode/longview.log.

      Debug Mode

      Restart the Longview client in debug mode for increased logging verbosity.

      1. First stop the Longview client:

        CentOS, Debian, and Ubuntu

        sudo systemctl stop longview   # For distributions with systemd.
        

        Other Distributions

        sudo service longview stop     # For distributions without systemd.
        
      2. Then restart Longview with the debug flag:

        sudo /etc/init.d/longview debug
        
      3. When you’re finished collecting information, repeat the first two steps to stop Longview and restart it again without the debug flag.

        If Longview does not close properly, find the process ID and kill the process:

        ps aux | grep longview
        sudo kill $PID
        

      Firewall Rules

      If your Linode has a firewall, it must allow communication with Longview’s aggregation host at longview.linode.com (IPv4: 96.126.119.66). You can view your firewall rules with one of the commands below, depending on the firewall controller used by your Linux distribution:

      firewalld

      sudo firewall-cmd --list-all
      

      Note

      iptables

      sudo iptables -S
      

      Note

      ufw

      sudo ufw show added
      

      Note

      If the output of those commands show no rules for the Longview domain (or for 96.126.119.66, which is the IP for the Longview domain), you must add them. A sample iptables rule that allows outbound HTTPS traffic to Longview would be the following:

      iptables -A OUTPUT -p tcp --dport 443 -d longview.linode.com -j ACCEPT
      

      Note

      If you use iptables, you should also make sure to persist any of your firewall rule changes. Otherwise, your changes will not be enforced if your Linode is rebooted. Review the iptables-persistent section of our iptables guide for help with this.

      Verify API key

      The API key given in the Linode Cloud Manager should match that on your system in /etc/linode/longview.key.

      1. In the Linode Cloud Manager, the API key is located in the Installation tab of your Longview Client instance’s detailed view.

      2. SSH into your Linode. The Longview key is located at /etc/linode/longview.key. Use cat to view the contents of that file and compare it to what’s shown in the Linode Cloud Manager:

        cat /etc/linode/longview.key
        

        The two should be the same. If they are not, paste the key from the Linode Cloud Manager into longview.key, overwriting anything already there.

      Cloned Keys

      If you clone a Linode which has Longview installed, you may encounter the following error:

        
      Multiple clients appear to be posting data with this API key. Please check your clients' configuration.
      
      

      This is caused by both Linodes posting data using the same Longview key. To resolve it:

      1. Uninstall the Longview agent on the cloned system.

        CentOS:

        sudo yum remove linode-longview
        

        Debian or Ubuntu:

        sudo apt-get remove linode-longview
        

        Other Distributions:

        sudo rm -rf /opt/linode/longview
        
      2. Add a new Linode Longview Client instance. This will create a new Longview API key independent from the system which it was cloned from.

        Note

        The GUID provided in the Longview Client’s installation URL is not the same as the Longview API key.

      3. Install the Longview Agent on the cloned Linode.

      If you still need assistance after performing these checks, please open a support ticket.

      This guide is published under a CC BY-ND 4.0 license.



      Source link