Fix Common WordPress Hosting Problems 2026: Memory, Error 500, Upload

Why WordPress Often Has Problems on Shared Hosting

Shared Hosting means sharing server resources with other users, which results in strict limits on RAM usage, CPU time, and PHP configuration values. The default PHP memory_limit on Shared Hosting is typically 64MB or 128MB, which may be insufficient for WordPress installations running many plugins. Similarly, max_execution_time and upload_max_filesize are often set to low defaults that can cause unexpected failures during normal site operations.

WordPress is a highly extensible CMS, but modern plugins and themes demand more resources over time. WooCommerce requires at least 256MB of RAM, page builders like Elementor consume both CPU and RAM heavily on every request, and SEO plugins like Yoast run processing on every page load. Running multiple resource-intensive plugins simultaneously can exhaust available memory instantly, triggering errors that appear unrelated to resource limits.

DirectAdmin users on AsiaGB can check resource usage in the DirectAdmin Dashboard by reviewing MySQL Usage, Disk Usage, and CPU/Memory statistics under Account Information. This gives a clear view of whether problems stem from exhausted resources or other causes. AsiaGB Hosting uses SSD storage, which significantly reduces read/write latency for MySQL queries and WordPress file operations compared to traditional HDD setups, making WordPress noticeably faster even on a shared environment.

Fix "Fatal error: Allowed memory size" — Memory Limit Exceeded

The error "Fatal error: Allowed memory size of XXXXXXX bytes exhausted" occurs when a PHP script consumes more memory than the limit set in php.ini. Common causes include WooCommerce loading large Cart and Session objects, page builders such as Elementor or WPBakery rendering multiple CSS and JavaScript layers simultaneously, WPML loading multi-language data structures on every request, and Revolution Slider processing animation configurations during page load.

There are three primary methods to increase the Memory Limit. You can use any single method or combine them. Start with Method 1, and proceed to the next if the change does not take effect immediately.

Method 1: Edit wp-config.php

Open wp-config.php via DirectAdmin File Manager and add these lines before the "That's all, stop editing!" comment.

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

Method 2: Edit .htaccess

Open the .htaccess file in the WordPress root folder and add this line above the "# BEGIN WordPress" section.

php_value memory_limit 256M

Method 3: Edit php.ini

Create or edit a php.ini file in the WordPress root folder with the following content.

memory_limit = 256M

After making changes, verify the result by creating a temporary phpinfo.php file in the WordPress folder, opening it in a browser, and searching for "memory_limit". Confirm the value has updated, then delete phpinfo.php immediately. On DirectAdmin, you can also configure this through Domain Setup > PHP Configuration > Extra PHP Configuration without touching any files directly.

Fix HTTP Error 500 Internal Server Error on WordPress Hosting

HTTP Error 500 is a generic server-side error that provides no specific detail on screen. The most common causes on Shared Hosting include a corrupted .htaccess file containing directives the server does not support, plugin conflicts that cause fatal PHP errors, memory exhaustion, or a syntax error in the active theme's functions.php file. Follow these steps in sequence until you identify the root cause.

Step 1: Rename .htaccess to .htaccess.bak

Open DirectAdmin File Manager, navigate to the WordPress root folder (typically public_html), and rename .htaccess to .htaccess.bak. If the site becomes accessible again, go to WordPress Admin > Settings > Permalinks and click Save Changes to let WordPress regenerate a clean, correct .htaccess file automatically.

Step 2: Disable All Plugins via File Manager

Navigate to wp-content/plugins/ in DirectAdmin File Manager and rename the "plugins" folder to "plugins_disabled". WordPress will be unable to load any plugins. If the site recovers, rename the folder back to "plugins" and reactivate plugins one by one to identify which plugin is causing the conflict.

Step 3: Switch to a Default Theme (Twenty Twenty-Four)

If plugins are not the cause, rename the current theme's folder in wp-content/themes/ so WordPress falls back to a built-in default theme automatically. This isolates whether the active theme's code — particularly functions.php — is causing the error.

Step 4: Increase Memory Limit

Follow the memory limit increase methods described in the previous section. Many Error 500 instances are caused by memory exhaustion that WordPress does not surface with a visible "Allowed memory size" message, making memory the silent cause of many 500 errors.

Step 5: Check the Error Log in DirectAdmin

In DirectAdmin, go to Extra Features > Error Logs, or locate the error.log file in the Domain's logs/ folder via File Manager. The Error Log shows the exact file and line number where the problem occurred, making it the fastest and most reliable path to identifying the definitive fix.

A standard, clean WordPress .htaccess that works correctly on Apache hosting:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Fix Image/Video Upload Errors in WordPress (Max Upload Size)

When WordPress displays "The uploaded file exceeds the upload_max_filesize directive in php.ini" or simply "HTTP Error" during an upload attempt, it means PHP is blocking the file due to size restrictions. Three PHP directives govern this behavior: upload_max_filesize, post_max_size, and max_execution_time. All three must be set correctly and in relation to each other.

The critical dependency is that post_max_size must be equal to or greater than upload_max_filesize. If post_max_size remains at 8M while upload_max_filesize is set to 64M, uploads will still fail for files larger than 8MB regardless of the first setting.

Fix via php.ini

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300

Fix via .htaccess

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

Fix via wp-config.php

@ini_set('upload_max_size', '64M');
@ini_set('post_max_size', '64M');
@ini_set('max_execution_time', '300');

On DirectAdmin, PHP values can be adjusted at Domain Setup > PHP Configuration > Extra PHP Configuration. After saving, verify by going to WordPress Admin > Media > Add New. The "Maximum upload file size" figure displayed there should reflect the new limit you configured.

Fix WordPress White Screen of Death (WSOD)

The White Screen of Death is a completely blank white page with no text, error messages, or visible content. It occurs when a PHP Fatal Error stops WordPress before it can output any HTML to the browser. Common causes include plugin conflicts, a PHP syntax error in the active theme's functions.php, or memory exhaustion occurring during the page rendering process before output begins.

The first and most effective step is enabling Debug Mode to capture specific error details. Edit wp-config.php as follows:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Setting WP_DEBUG_DISPLAY to false prevents errors from appearing on-screen for security reasons, while WP_DEBUG_LOG writes all errors to wp-content/debug.log. Open that file in DirectAdmin File Manager to read the error output, which specifies exactly which file and line number caused the failure — giving you a clear action item to resolve.

If plugins are responsible for the WSOD, rename the plugins folder in wp-content/ to disable all of them at once. If the theme is the likely cause, rename the active theme's folder. If the issue may stem from PHP version incompatibility, check DirectAdmin's PHP Version Manager and switch to the PHP version the plugin or theme requires. Some plugins do not yet support PHP 8.x and require PHP 7.4 to function correctly.

Fix "Your PHP installation appears to be missing the MySQL extension"

The message "Your PHP installation appears to be missing the MySQL extension which is required by WordPress" indicates that the mysqli or mysqlnd PHP extension is not enabled for the currently active PHP version. This typically occurs after switching to a newer PHP version where the required database extensions were not carried over in the enabled state.

Steps to resolve on DirectAdmin:

1. Log in to DirectAdmin with your user account credentials.
2. Navigate to Domain Setup and select the affected domain.
3. Open PHP Version Selector to view and change the active PHP version.
4. Select PHP 7.4, 8.0, 8.1, or 8.2 based on your plugin requirements.
5. Verify that the "mysqli" and "mysqlnd" extensions are enabled in the Extensions list.
6. Click Save and allow a moment for the PHP configuration to reload across the server.

WordPress 6.x requires PHP 7.4 as a minimum, but PHP 8.1 or 8.2 is strongly recommended for the best performance and ongoing security maintenance. PHP 8.1 benchmarks approximately 20 to 30 percent faster than PHP 7.4 according to PHP Foundation performance tests. After switching PHP versions, clear OPcache through DirectAdmin or your caching plugin to ensure the new version's bytecode is used rather than cached data from the previous version.

Fix WordPress Login Loop (Redirect Not Stopping)

A Login Loop occurs when submitting credentials on the WordPress login page redirects back to the login form repeatedly without granting access to the Admin area. Common causes include a mismatch between the siteurl or home values stored in the Database and the actual URL of the site, corrupted or incomplete browser cookies, or an SSL redirect configuration that causes Mixed Content issues preventing cookies from being sent correctly.

Fix 1: Define URLs in wp-config.php

Open wp-config.php and add these lines before "That's all, stop editing!", substituting example.com with your real domain name.

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Fix 2: Clear Browser Cookies and Cache

Delete all browser cookies and attempt to log in again using an Incognito or Private Browsing window. This rules out corrupted or expired cookie data stored by the browser as a contributing factor.

Fix 3: Correct Database Values via phpMyAdmin in DirectAdmin

In DirectAdmin, navigate to MySQL Management and launch phpMyAdmin. Access the WordPress database, select the wp_options table, and locate rows with option_name "siteurl" and "home". Verify that each option_value matches the actual URL of the site. If the values are incorrect, click Edit and update them to the correct URL including the protocol (https://).

Fix 4: Force SSL Redirect in .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Fix 5: Flush Rewrite Rules

After correcting any URL values, go to WordPress Admin > Settings > Permalinks and click Save Changes without modifying any settings. This forces WordPress to regenerate its rewrite rules correctly and clears any cached routing data that may have contributed to the loop.

Fix 404 Not Found After Installing WordPress on Hosting

A 404 Not Found error appearing after a successful WordPress installation is almost always caused by mod_rewrite not functioning, or by a missing or incorrect .htaccess file. mod_rewrite is the Apache module that WordPress requires to convert user-friendly URLs like /my-post/ into the internal query string format /?p=1 behind the scenes. Without it, every URL except the homepage returns a 404 error.

Step 1: Re-save Permalinks

Go to WordPress Admin > Settings > Permalinks and click Save Changes without modifying any existing settings. WordPress will automatically regenerate the .htaccess file with the correct rewrite rules. This single action resolves the issue in the vast majority of cases.

Step 2: Verify the .htaccess File Exists in DirectAdmin File Manager

In DirectAdmin File Manager, navigate to public_html and confirm that a .htaccess file exists. You must enable "Show Hidden Files" in File Manager settings because .htaccess is a hidden file by default and will not appear otherwise. If absent, create a new .htaccess file and insert the standard WordPress rewrite rules:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Step 3: Confirm mod_rewrite is Enabled on the Server

If .htaccess is in place and correct but 404 errors persist on all pages, contact AsiaGB Support to verify that mod_rewrite is enabled on the server. The support team can confirm and enable it immediately. A common additional cause is installing WordPress in a subdirectory such as public_html/wordpress/ while expecting it to serve from the root domain — this requires additional steps in WordPress Admin > Settings > General to configure the correct site and home URLs.

How to View PHP Error Log in DirectAdmin to Debug WordPress

The PHP Error Log is a text file that records all PHP errors as they occur in real time. It is the single most powerful debugging tool available for WordPress on Shared Hosting, providing far more detail than any error message displayed on screen. Critically, it also captures errors that occur before WordPress has finished loading — making it the only tool capable of diagnosing blank pages and complete startup failures.

On DirectAdmin, Error Logs are accessible through Extra Features or the Error Logs section of the Account Manager. You can also enable PHP error logging directly via php.ini or .htaccess for more granular control over where logs are written.

Enable PHP Error Logging via php.ini

log_errors = On
error_log = /home/username/logs/php_errors.log
error_reporting = E_ALL

Enable via .htaccess

php_flag log_errors on
php_value error_log /home/username/logs/php_errors.log

Once enabled, access the log file through DirectAdmin File Manager by navigating to the logs/ folder within your account's home directory. Common error patterns to recognize include "PHP Fatal error: Call to undefined function" indicating a function called before its plugin loaded, "PHP Warning: include(): Failed opening" pointing to a missing file reference, and "PHP Parse error: syntax error, unexpected" revealing recently edited code with a syntax mistake.

The key distinction between WP Debug Log and PHP Error Log lies in their scope. WP Debug Log at wp-content/debug.log records only errors that WordPress itself intercepts and handles. The PHP Error Log captures errors at every PHP level, including those occurring before WordPress initializes. When WordPress fails to load at all and the debug.log file is empty or absent, the PHP Error Log is the definitive source of truth for the root cause.

FAQ

Q: Do I need to add more RAM to the server to fix the Memory Limit error?

A: No. Increasing PHP memory_limit in wp-config.php, .htaccess, or php.ini instructs PHP to allow this particular script to use more of the available server RAM up to the specified ceiling. The change takes effect immediately with no hardware modifications required and is the standard solution on Shared Hosting.

Q: Where is wp-config.php located?

A: It resides in the WordPress installation root. On DirectAdmin at AsiaGB, the typical path is /home/username/domains/example.com/public_html/wp-config.php. You can access and edit it via DirectAdmin File Manager or any FTP client.

Q: I followed all the steps for Error 500 but the site still does not work. What next?

A: Submit a support ticket at billing.in.th to request that the AsiaGB support team review the Server Error Log directly. They have access to server-level logs that provide more detail than is available to regular user accounts, and can usually identify the root cause quickly.

Q: Which plugins consume the most memory in WordPress?

A: The highest memory consumers are typically WooCommerce, Elementor, WPBakery, WPML, Revolution Slider, and backup plugins of all kinds. Use only the plugins you genuinely need, remove inactive plugins entirely, and keep all active plugins updated to ensure optimal resource usage.

Q: Which PHP version should I use with WordPress 6.x?

A: WordPress 6.x requires at least PHP 7.4, but PHP 8.1 or 8.2 is the recommended choice for the best performance and continued security support. You can change the PHP version at any time through DirectAdmin's PHP Selector without needing to contact support.