Wordpress – DeBug Steps –

[display-posts category=”wordpress, wordpressmorecheats” category_display=”true” category_display=”post_tag” category_display=”taxonomy_name” include_excerpt=”true” image_size=”display-posts-nav-img” wrapper=”div” wrapper_class=”display-posts-listing grid” meta_key=”_thumbnail_id” pagination=”true” pagination=”1″]


h3>Debug File Settings

https://www.a2hosting.com/kb/installable-applications/optimization-and-configuration/wordpress2/debugging-wordpress

To enable debugging mode in WordPress, follow these steps:

Log in to cPanel, or access your account using SSH.
Using the cPanel File Manager or the SSH command prompt, open the wp-config.php file in your preferred text editor.
To enable debugging mode, add the following line to the wp-config.php file:

define(‘WP_DEBUG’, true);

When this setting is enabled, WordPress displays all PHP errors, notices, and warnings.
Save your changes and exit the text editor. Debugging mode is now active.

When you are done, disable debugging mode by modifying the line in the wp-config.php file as follows:

define(‘WP_DEBUG’, false);

ADDITIONAL DEBUGGING OPTIONS
There are several additional settings you can use to control the debugging information that WordPress provides:

WP_DEBUG_LOG: When WP_DEBUG_LOG and WP_DEBUG are enabled, WordPress saves all error information to the debug.log file in the wp-content directory. By default, this setting is disabled.
To enable this setting, add the following line to the wp-config.php file:

define(‘WP_DEBUG_LOG’, true);

WP_DEBUG_DISPLAY: When WP_DEBUG_DISPLAY and WP_DEBUG are enabled, WordPress displays error and warning messages on web pages. By default, this setting is enabled. When this setting is disabled, debugging messages are hidden from view.

To disable this setting, add the following line to the wp-config.php file:

define(‘WP_DEBUG_DISPLAY’, false);

SCRIPT_DEBUG: When SCRIPT_DEBUG is enabled, WordPress uses development versions of core CSS and JavaScript files instead of the compressed versions that it normally uses. By default, this setting is disabled. You can use this setting to test modifications to built-in .js or .css files.
To enable this setting, add the following line to the wp-config.php file:

define(‘SCRIPT_DEBUG’, true);

LOGGING DATABASE QUERIES
If you are experiencing database issues with WordPress, you can enable query logging. When query logging is enabled, the following items are saved in the global $wpdb->queries array:

The actual database query.
How long the query takes to run.
The function that called the query.
To enable database query logging, add the following line to the wp-config.php file:

define(‘SAVEQUERIES’, true);

Enabling this setting affects your site’s performance. You should only enable this setting for as long as it is necessary to debug a problem, and then disable it.
The following PHP code snippet demonstrates how to dump the entire contents of the $wpdb->queries array to a page:

queries );
?>

MORE INFORMATION
To view the official WordPress debugging documentation, please visit https://codex.wordpress.org/Debugging_in_WordPress.




Revert back to previous version of wordpress

https://www.wpkube.com/downgrade-wordpress-versions-plugins-themes-might-want/

However, despite extensive testing, it’s impossible to discover every bug and sometimes some do get through. More often, plugins don’t play nicely with the newer version of WordPress and it can take some time for plugin developers to catch up and release a new version.

so it is possible that it could be the new version of wordpress that is causing errors

5.2 has issues

https://wordpress.org/support/topic/read-this-first-wordpress-5-2-master-list/


woocommerce conflicts

https://docs.woocommerce.com/document/how-to-test-for-conflicts/


Elementor Fixes

https://docs.elementor.com/article/245-preview-could-not-be-loaded

How to Fix the ‘Preview Could Not Be Loaded’ Error
Are you seeing an error when you try to use Elementor that states: ‘Preview could not be loaded’? This is one of the most common errors on Elementor, and usually, it is quite easy to fix.


Turn on Reporting

Close monitoring of your site’s PHP errors is crucial to operating a healthy, secure, and well-performing website. When left undetected, PHP errors can reduce performance, waste bandwidth, and leave your site vulnerable to malicious attack. PHP errors usually occur unpredictably and spontaneously, and may be triggered by even the slightest changes to your server configuration, database setup, or WordPress files. Even if your site appears to working properly on the surface, it may in fact be suffering from undetected PHP errors that should be fixed as soon as possible.

Monitoring PHP errors is something that all responsible WordPress administrators should be doing. In this DiW article, we’ll show you three easy ways to monitor PHP errors for WordPress. The first method is exclusive to WordPress, and the second two methods work great for any website.

Method 1: Error Logging via the WordPress configuration file

Perhaps the easiest way to implement PHP error-logging for your WordPress-powered site is to add a few simple lines of code to your [code language=”css”]wp-config.php[/code] file. The WordPress [code language=”css”]wp-config.php[/code] file may be used to specify various PHP initiation settings to modify the functionality of your PHP installation. In this method, we will take advantage of this feature by implementing basic error monitoring for your site. Here’s how to do it:

Step 1: Create a log file

Create an empty file called “[code language=”css”]php-errors.log[/code]”. This file will serve as your site’s PHP error log. Your server will need write access to this file, so make sure to set the appropriate permissions. This file may be placed in any directory, but placing it above the web-accessible root directory of your site is advisable for security reasons. Once this file is created, writable, and in place, take note of its absolute directory path and continue to the final step.

BASICALLY YOU HAVE TO USE CPANEL OR SOMETHING TO ADD FILE

If you turn define(‘WP_DEBUG’, false); to true -then the errors show up on front end and in log – can be useful – 2x checked – they DO show up in log –

To determine the absolute path of your log file, upload a PHP with the following code to the same directory and open it in a browser:

[code language=”css”]<?php echo $_SERVER[‘DOCUMENT_ROOT’]; ?>[/code]

Depending on your server configuration, you may need to use method #1 or #2 if you are running PHP5. Certain dual-PHP setups and other configurations may require any php_value directives to be placed in a php.ini file instead of htaccess.

An easy way to test that your error-logging system is working is to trigger a few basic PHP errors. To do so, create a PHP file and add something that will trigger an error, for example:

[code language=”css”]<?php echo "error" ?>[/code]

Lastly, if you are triggering errors but nothing is being written to your log file, triple-check that the file is writable by the server. Depending on your particular server configuration, you may need to increase the permissions level of the file. If you have to run with a setting of “777” (full permissions), definitely make sure that the log file is placed above the web-accessible root directory of your site.

Step 2: Add the magic code

Next, open your site’s [code language=”css”]wp-config.php[/code] file (located in the root WordPress directory) and place the following code immediately above the line that says, “[code language=”css”]That’s all, stop editing! Happy blogging.[/code]”:

[code language="css"]// log php errors
@ini_set('log_errors','On'); // enable or disable php error logging (use 'On' or 'Off')
@ini_set('display_errors','Off'); // enable or disable public display of errors (use 'On' or 'Off')
@ini_set('error_log','/home/path/logs/php-errors.log'); // path to server-writable log file[/code]

Once in place, edit the third line with the absolute directory path to the [code language=”css”]php-errors.log[/code] file created in the first step. Upload to your server and call it done. All PHP errors will now be logged to your [code language=”css”]php-errors.log[/code] file, thereby enabling you to monitor and resolve errors as quickly as possible.
The other two directives in this tasty little snippet enable you to log and display PHP errors at your will. The current configuration is ideal for production sites, but you may want to enable PHP error display for development purposes. See the code comments for more information on changing these settings.

Cool tips

A couple of notes regarding this method.. First, if you place the following definition to your [code language=”css”]wp-config.php[/code] file, all WordPress debug errors will also be written to your [code language=”css”]php-errors.log[/code] file:
[code language=”css”]define(‘WP_DEBUG’, true); // enable debugging mode[/code]
Also note that the code used for this example demonstrates a very basic implementation. You may add any number of additional [code language=”css”]@ini_set()[/code] directives to enhance and customize your error-logging system as needed.

Method 2: Error Logging via the php.ini file

If you have access to your site’s [code language=”css”]php.ini[/code] file, or if you are able to implement “per-directory” initiation files, this method will enable you to monitor PHP errors for any website, not just those powered by WordPress. The process is very similar to the previous method, and requires the following two steps:

Step 1: Create a log file

Create an empty file called “[code language=”css”]php-errors.log[/code]”. This file will serve as your site’s PHP error log. Your server will need write access to this file, so make sure to set the appropriate permissions. This file may be placed in any directory, but placing it above the web-accessible root directory of your site is advisable for security reasons. Once this file is created, writable, and in place, take note of its absolute directory path and continue to the final step.

Step 2: Add the magic code

Next, open your site’s [code language=”css”]php.ini[/code] file and add the following code:

[code language="css"];;; log php errors
display_startup_errors = false
display_errors = false
html_errors = false
log_errors = true
track_errors = true
error_log = /home/path/logs/php-errors.log
error_reporting = E_ALL | E_STRICT
log_errors_max_len = 0[/code]

As before, this code is configured for optimal error-handling for production servers. The only thing that you need to edit is the absolute directory path for your log file. During site development, you may want to change some of the variables to enable error display, startup errors, repeat errors, and so forth. For more information on these directives, and for a more in-depth guide to logging errors with PHP, check out my article at Perishable Press, Advanced PHP Error Handling via PHP.

Method 3: Error Logging via the HTAccess file

Last but not least, let’s look at how to enable PHP error-logging via HTAccess. This method works great if HTAccess files are enabled on your site, and will enable you to log PHP errors on any site, not just those powered by WordPress. The process is very similar to the previous method, and requires the following two steps:

Step 1: Create a log file

Create an empty file called “[code language=”css”]php-errors.log[/code]”. This file will serve as your site’s PHP error log. Your server will need write access to this file, so make sure to set the appropriate permissions. This file may be placed in any directory, but placing it above the web-accessible root directory of your site is advisable for security reasons. Once this file is created, writable, and in place, take note of its absolute directory path and continue to the final step.

Step 2: Add the magic code

Next, open your site’s root [code language=”css”].htaccess[/code] file and add the following code:

[code language="css"]# log php errors
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_flag  log_errors on
php_value error_log /home/path/logs/php-errors.log[/code]

As before, this code is configured for optimal error-handling for production servers. The only thing that you need to edit is the absolute directory path for your log file. During site development, you may want to change some of the variables to enable error display, startup errors, repeat errors, and so forth. For more information on these directives, and for a more in-depth guide to logging PHP errors via HTAccess, check out my article at Perishable Press, Advanced PHP Error Handling via htaccess.

Troubleshooting Tips

To determine the absolute path of your log file, upload a PHP with the following code to the same directory and open it in a browser:
[code language=”css”]&lt;h3&gt;&lt;?php echo $_SERVER[‘DOCUMENT_ROOT’]; ?&gt;&lt;/h3&gt;[/code]
Depending on your server configuration, you may need to use method #1 or #2 if you are running PHP5. Certain dual-PHP setups and other configurations may require any [code language=”css”]php_value[/code] directives to be placed in a [code language=”css”]php.ini[/code] file instead of [code language=”css”]htaccess[/code].
An easy way to test that your error-logging system is working is to trigger a few basic PHP errors. To do so, create a PHP file and add something that will trigger an error, for example:
[code language=”css”]&lt;?php echo "error" ?&gt;[/code]
Lastly, if you are triggering errors but nothing is being written to your log file, triple-check that the file is writable by the server. Depending on your particular server configuration, you may need to increase the permissions level of the file. If you have to run with a setting of “[code language=”css”]777[/code]” (full permissions), definitely make sure that the log file is placed above the web-accessible root directory of your site.

Wrap it up then

With one of these three PHP error-logging techniques, you have everything you need to implement easy, automatic error-logging for your website. Everything happens quietly behind the scenes, so remember to keep an eye on things by checking your log file periodically. Doing so will enable you to ensure a well-performing site and the best possible experience for your visitors.


Out of Memory Limit Error

https://www.wpbeginner.com/wp-tutorials/fix-wordpress-memory-exhausted-error-increase-php-memory/

ERROR::
“Your PHP code changes were rolled back due to an error on line 541 of file wp-content/plugins/woocommerce/includes/admin/class-wc-admin-post-types.php. Please fix and try saving again.

Out of memory (allocated 110362624) (tried to allocate 49152 bytes)”

Next, you need to paste this code in wp-config.php file just before the line that says ‘That’s all, stop editing! Happy blogging.’

+++++++++++++++++
If you want to see what your php memory limit is, or where your php.ini file is located on your server you can put this code in a file, and name it something like phpinfo.php

This file should be located in your main website root directory. It will tell you all about your php installation including which modules are loaded, memory limits, and much more.

so max for caviar is 256MB – so can’t increase – php can’t do more than server – will ask them if we can have more –

+++++===+++++======+==+=+=+=+=+=+=========++=+=+=

TO INCREASE MEMORY LIMIT –

[code language=”css”]
define( ‘WP_MEMORY_LIMIT’, ‘256M’ );
[/code]


woocommerce removal

  • If you deactivate and delete the plugin from WordPress, you only remove the plugin and its files. Your settings, orders, products, pages, etc… will still exist in the database.
  • If you need to remove ALL WooCommerce data, including products, order data, etc., you need to be able to modify the site’s wp-config.php file to set a constant as true.

Open your site’s wp-config file and add
define( ‘WC_REMOVE_ALL_DATA’, true);
on its own line above the /* That’s all, stop editing! Happy blogging. */ line. Then when you deactivate and delete WooCommerce it will remove all of its data.


Overall Debug Steps

Before posting, please make sure you’ve tried started by performing the troubleshooting steps outlined below:

  • Flushing any caching plugins you might be running, as well as server and/or . Not just your browser, but any op cache or content network cache as well . That will solve many weird JavaScript issues.
  • Flushing Managed host caches. Managed WP hosting often has special caches. If your host has a “Purge Varnish” or “Flush Memcache” tool, try that. You can ask your provider to flush memcache and Varnish for you if necessary.
  • Resave your Permalink settings. In a few cases, we’ve seen third-party installers, such as Softaculous, creating sites with slightly incorrect rules in the .htaccess file. While these rules would not have been a problem in previous versions, in WordPress 5.0, having these incorrect rules can break the REST API. Resaving the permalinks on the Settings->Permalinks page in WordPress will fix these rules in the .htaccess file, and possibly fix “failed” errors in the new editor.
  • Troubleshooting with your browser. Your browser can help you identify JavaScript issues or conflicts and . This could help identify Visual Editor issues as well.
  • Make sure you have the Visual Editor enabled. Visit your Users->Your Profile page. The first option will disable the visual editor. Make sure that option is unchecked, and save your profile settings.
  • Deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by or PhpMyAdmin (read “” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
  • Switching to the Twenty Nineteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via so the only one is twentynineteen. That will force your site to use it.
  • Manually upgrading. When all else fails, download a fresh copy of the latest.zip file of 5.0.* (top right on this page) to your computer, and use that to copy up. You may need to delete the wp-admin and wp-includes folders on your server (NOTE: do not delete the wp-content directory or your wp-config.php file) Read the .
  • If you can install plugins, install “Health Check”: https://wordpress.org/plugins/health-check/. On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.

If you need to create a support topic, you can provide debug data for the support volunteers by visiting the Site Health section under Tools > Site Health > Info.


Upgrading Php

Updating your PHP version should not be a problem, but we can’t guarantee that it’s not. WordPress itself works with PHP versions as far back as 5.6.20 (we’re currently recommending version 7.3, so this is great backward compatibility!), but we don’t know if your themes or plugins will work. They should, and popular or reputable ones almost certainly will be, but we can’t guarantee it.

Steps to take before upgrading

  • Make a backup of your website: a backup will let you revert your site to how it is right now in the event anything goes wrong. There are plenty of free backup plugins available, so if you don’t have a backup solution already – use one of these. In order to revert this backup, you’ll also need your web host to move your PHP version back to your current version (we’ll cover how to do this later).
  • Update WordPress, themes, and plugins: from your WordPress Dashboard, head to Updates, and then update all. You should do this regularly anyway. ? When done, check your site is working as expected.
  • Check PHP compatibility: install the PHP Compatibility Checker plugin to check your themes and plugins for possible issues. This plugin isn’t perfect and may miss items or flag false positives, but it does work in most cases.
  • Fix any PHP compatibility issues: if the PHP Compatibility Checker plugin picks up any issues, get in touch with the theme or plugin developer and ask them to investigate. If they can’t or won’t get back to you, have a look for themes or plugins on WordPress.org with similar functionality and use one of these instead.

can’t upload to media library

1. Make Sure The HTTP Error is Not Temporary
Wait and try again – server my self correct

2. Try different type of image

3. Increase WordPress Memory Limit
[code language=”css”]
define( ‘WP_MEMORY_LIMIT’, ‘256M’ );
[/code]
This code increases the WordPress memory limit to 256MB, which would be enough to fix any memory limit issues.

4. Change Image Editor Library Used by WordPress
WordPress runs on PHP which uses two modules to handle images. These modules are called GD Library and Imagick. WordPress may use either one of them depending on which one is available.

However, Imagick is known to often run into memory issues causing the http error during image uploads. To fix this, you can make the GD Library your default image editor.

You can do this by simply adding this code to your theme’s functions.php file or a site-specific plugin.

[code language=”css”]
function wpb_image_editor_default_to_gd( $editors ) {
$gd_editor = ‘WP_Image_Editor_GD’;
$editors = array_diff( $editors, array( $gd_editor ) );
array_unshift( $editors, $gd_editor );
return $editors;
}
add_filter( ‘wp_image_editors’, ‘wpb_image_editor_default_to_gd’ );
[/code]

After adding this code, you can retry uploading files using the media uploader. If this doesn’t solve the issue, then you can remove this code and try other methods described in this article.

5. Using The .htaccess Method
This method allows you to control how Imagick uses server resources. Many shared hosting providers limit Imagick’s ability to use multiple threads for faster image processing. However, this would result in you seeing the http error when uploading images.

An easy fix is be to add the following code in your .htaccess file:

[code language=”css”][/code]
SetEnv MAGICK_THREAD_LIMIT 1
[code][/code]


5.2 ISSUES

Core Changes

Site Health Check
Building on the Site Health features introduced in 5.1, this release adds two new pages to help debug common configuration issues. It also adds space where developers can include debugging information for site maintainers. Check your site status, and learn how to debug issues.

PHP Error Protection
This administrator-focused update will let you safely fix or manage fatal errors without requiring developer time. It features better handling of the so-called “white screen of death,” and a way to enter recovery mode, which pauses error-causing plugins or themes.

Accessibility Updates
A number of changes work together to improve contextual awareness and keyboard navigation flow for those using screen readers and other assistive technologies.

New Dashboard Icons
Thirteen new icons include Instagram, a suite of icons for BuddyPress, and rotated Earth icons for global inclusion. Find them in the Dashboard and have some fun!

ModeratorMarius L. J. (@clorith)
2 weeks, 4 days ago
Not a bug
Noteworthy and recurring scenarios users are encountering that are not actually bugs, but rather changed or new behaviors.

I am unable to update: The update cannot be installed because WordPress 5.2 requires PHP 5.6.20 or higher.
With WordPress 5.2 we increased the minimum PHP requirement for running the software. If you are seeing this message, check if your web-host has any documentation relating to upgrading your PHP version, or reach out to your server admin/support team for assistance in doing so.

But I’m running PHP 5.6.3, isn’t that higher than PHP 5.6.20?

No, PHP versions, and most software versions, do not follow how decimals work in math and such. In this case, PHP 5.6.20 is higher than PHP 5.6.3, because 20 is higher than 3.

I don’t agree with Health Check’s score!

That’s ok! Here are a few things to keep in mind:

  1. Health Check will direct you to what the WordPress core developers consider to be the best case scenario for a WordPress installation.

  2. Health Check cannot read your mind to determine the context behind your own decisions.

  3. You do not need to win a perfect score in Health Check.

  4. This is your WordPress installation, which you can choose to run as you see fit.

The site is experiencing technical difficulties.
WordPress 5.2 introduces new protection from sites crashing due to bad code (also known as a White Screen of Death, or WSOD for short).

If your site crashes, the message above is shown, and an email is sent to the site admin with a way to log in and deactivate the plugin or theme causing problems, once that is done the site should start working again as expected.


Master list of Debug


Are you encountering a common WordPress error on your site? Do you want to troubleshoot these WordPress errors on your own? Most of these errors can be solved by following easy troubleshooting steps. In this beginner’s guide, we will show you how to troubleshoot WordPress errors one step at a time.
Troubleshooting WordPress errors
Troubleshooting WordPress errors

1. Create a Complete Backup of Your WordPress Site

First thing you should do is to create a complete backup of your WordPress site. If you were already using a WordPress backup plugin, then make sure that you have a recent backup safely stored somewhere.
If you were not using a backup plugin, then you should start using one immediately. However, in case you don’t have access to the admin area of your WordPress site, then you will need to manually backup your database and files.
Backups allow you to restore your WordPress site easily when something goes wrong. They are your first and most important defence against security threats, hacking, and data loss.

2. Deactivate All Plugins Installed on Your Website

Most of the times errors are caused by a plugins conflicting with each other, your theme, or the WordPress core. Deactivating all WordPress plugins on your site will most likely solve the problem. You can then find out which plugin was causing the issue by activating plugins one by one on your site.
If you have access to the admin area of your WordPress site, then simply head over to the plugins page.

Select and deactivate all plugins in WordPress
Select and deactivate all plugins in WordPress

First you need to select all plugins, and then select ‘Deactivate’ from ‘Bulk Actions’ drop down menu. Click on the Apply button to deactivate all selected plugins.
If you do not have access to the admin area, then you will need to use FTP or phpMyAdmin to deactivate all plugins.
Simply connect to your website using an FTP client. If you haven’t used FTP before, then you may want to see our how to use FTP to upload files to WordPress.
Navigate to the wp-content folder and rename plugins folder to “plugin.deactivate”.
Rename plugins folder using FTP
Rename plugins folder using FTP

For more detailed instructions, see our article on how to deactivate all plugins when not able to access wp-admin.

3. Switch to a Default WordPress Theme

Sometimes your WordPress theme can cause issues on your site. You can easily find out if your theme is causing an issue by switching to a default WordPress theme like Twenty Sixteen or Twenty Fifteen.
Head over to Appearance » Themes page and then click on the Activate button next to a default theme.

Switch to a default WordPress theme
Switch to a default WordPress theme

However, if you don’t have access to the admin area of your WordPress site, then you will need to use FTP to switch theme.
Connect to your website using an FTP client and then navigate to /wp-content/themes/ folder. Download your current active theme as a backup to your Desktop.
After that you need to delete all themes except a default WordPress theme like TwentySixteen. Since your active theme will no longer be available, WordPress will now automatically switch to using the default theme available.
If your theme was causing the issue, then you should be able to log in to your WordPress site now.

WordPress uses SEO friendly URL structure or Permalinks. Sometimes the permalink structure is not updated or configured properly, which may result in unexpected 404 errors on your site.
You can easily refresh permalinks without changing anything on your WordPress site. Visit Settings » Permalinks page and click on ‘Save Changes’ button without changing anything.

Update permalinks in WordPress
Update permalinks in WordPress

5. Backup and Delete .htaccess File

A corrupt .htaccess file is often the cause of the internal server error.
First you need to connect to your website using an FTP client. The .htaccess file is located in your site’s root directory.
Since it is a hidden file, you may need to force your FTP client to show hidden files. See our article on why you can’t find .htaccess file on your WordPress site
You need to download the .htaccess file to your computer as a backup, and then delete it from your web server.
You can now try to login to your WordPress site and go to Settings » Permalinks page. Click on the Save Changes button to refresh your permalinks and to regenerate a new .htaccess file for your site.

6. Fix WordPress Site URL

Having incorrect settings for WordPress URL and Site URL options can also cause redirect issues, 404 errors, and some other common issues.
WordPress URL and Site URL options can be changed from admin area by visiting Settings » General page.

Changing WordPress Address and Site Address options from admin area
Changing WordPress Address and Site Address options from admin area

Make sure that both URLs are exactly the same.
If you do not have access to the admin area of your WordPress site, then you can change these URLs using FTP. There are two ways to do that using FTP:
Update WordPress URL and Site URL Settings in wp-config.php File
Once connected to your website using an FTP client, locate wp-config.php file. Now you need to edit this file in a text editor like Notepad.
Go to the line that says [code language=”css”]/* That’s all, stop editing! Happy blogging. */[/code], and just before it, add this code:

1
2
define([/code]'WP_HOME'[/code],[/code]'http://example.com'[/code]);[/code]
define([/code]'WP_SITEURL'[/code],[/code]'http://example.com'[/code]);[/code]

Don’t forget to replace example.com with your own domain name. Now save your changes and upload the file back to your server.
Update URLs Using functions.php File
You can also update URLs using your theme’s functions.php file.
Open your FTP client and navigate to /wp-content/themes/ folder. Open your current active theme’s folder and locate functions.php file inside it. Now you will need to edit the functions.php file in a text editor like Notepad.
Simply add these lines at the bottom of the functions file:

1
2
update_option( [/code]'siteurl'[/code], [/code]'http://example.com'[/code] );[/code]
update_option( [/code]'home'[/code], [/code]'http://example.com'[/code] );[/code]

Don’t forget to change WordPress URLs from the settings page after you login to your site. Once you have added them on the settings page, you need to delete these lines from your theme’s functions file.

7. Check Reading Settings

If your newly created WordPress site is not indexed by search engines, then this is the first thing that you should do.
Login to your WordPress site and go to Settings » Reading page. Scroll down to the bottom of the page and make sure that the box next to ‘Search Engine Visibility’ is unchecked.

Search engine visibility
Search engine visibility

This option allows you to discourage search engines from showing your website in search. It is used by webmasters when they are working on a website which is not ready to be live. Sometimes you can accidentally check this setting and forget about it.
Make sure that this option is unchecked when your website is ready to go live.

8. Troubleshooting Email Issues

Many WordPress hosting providers do not have mail settings properly configured. This stops you and your users to receive emails from WordPress.
If you are using a contact form plugin, then you will not be able to receive those emails as well. You will also not receive any WordPress notifications.
See our complete step by step instructions in our article on how to fix WordPress not sending email issue.

9. Scanning for Malware and Backdoors

If you suspect that your WordPress site is affected with malware, then you should scan your website with Sucuri. It is the best website security monitoring service for WordPress site owners.
See our case study of how Sucuri helped us block 450,000 WordPress attacks in 3 months.
For more detailed instructions, see our guide on how to scan your WordPress site for potentially malicious code.

Getting Better Support

After following the above mentioned troubleshooting steps, you would be able to fix many of the most common WordPress errors. However, if the problem persists, then you can seek further support.
WordPress is a community software, so you can get help from the community by posting in WordPress support forums. Here is how to write a better support request:

  • Be polite and nice. No matter how upset or frustrated you are, do not use harsh language.
  • Mention your problem briefly.
  • Describe troubleshooting steps you have taken so far.
  • Uplaod screenshots on a cloud image sharing service, and then add the links in your support thread.

For more on this topic, take a look at our guide on how to properly ask for WordPress support and get it.
We hope this article helped you learn how to troubleshoot WordPress errors. You may also want to see our list of 14 most common WordPress errors and how to fix them.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

Scroll to Top