So you’ve got XAMPP installed and a fresh local installation of WordPress set up. Next, time to install that perfect theme. But wait! What’s this business about a fatal error and maximum execution time? Just when you thought you were past all the hard stuff…

Running into issues when developing with XAMPP is normal, especially if you’re working with it for the first time. When using XAMPP, following installation, installing a plugin, importing a large database, and creating a backup of your local website are all opportunities for something to go wrong. Just like any other server, a local XAMPP server will have to be adjusted for your particular computer setup to get it running problem-free.

PHP errors and port conflicts are the most common examples of the bugs XAMPP developers run into. Some of these issues are just about guaranteed to show up when working with a local WordPress installation, and in this tutorial, I’ll show you how to overcome four of the most common XAMPP issues WordPress developers are likely to encounter.

Trouble Shooting XAMPP & WordPress Issues

Problem 1: Maximum PHP Execution Time Exceeded

This is probably the most common issue first-time XAMPP users encounter. Try to install a large plugin or update the WordPress core and you’re almost guaranteed to see a fatal error message letting you know that the Maximum execution time of 30 seconds was exceeded.

error message stating that the maximum execution time has been exceeded

The good news is, this is a really simple problem to fix.

What’s going on is that the settings controlling the version of PHP running on your XAMPP installation are limiting script execution time to 30 seconds. However, it takes longer than 30 seconds to install large plugins, update the WordPress core or perform many other common WordPress operations.

To fix the issue, you need to adjust a single PHP setting in your XAMPP installation’s php.ini file.

There are two ways to get to this file.

  1. Open up XAMPP control panel, click on Config in the Apache row, and select PHP (php.ini). This will open the file in a text editor, but probably not your preferred text editor.
  2. Navigate to your root XAMPP folder, open the php directory and look for the file titled php.ini. Then open that file with your preferred text editor.

On my Windows laptop with XAMPP installed directly into the C: directory, the file is located at this address: C:xamppphpphp.ini.

Open php.ini in a text editor and find the line max_execution_time. If you’re running the latest version of XAMPP, it should appear on line 368 of the file. To increase the execution time, just input a larger number. The default value is 30 seconds, but many shared hosting environments set this limit at 120 seconds. Increasing this value to 120 should keep you from ever running into this particular issue again while working with WordPress websites.

maximum execution time increased to 120 seconds
120 seconds is commonly used by shared hosting providers, and should cover just about any WordPress operation.

Anytime you make a change to php.ini you must save the file, close it, and then stop and restart Apache in the XAMPP control panel. Apache only reads the values in php.ini when it starts up. So any changes made to php.ini while Apache is already running won’t take effect until Apache restarts and reads the new values.

Restart Apache and then reattempt the operation that caused the error to appear. You should now see things proceed as expected.

Problem 2: Maximum File Size Exceeded

This error can manifest itself for lots of different reasons. By far, the most common way to run into this error is when attempting to use the media uploader in WordPress to upload an image file larger than 2 MB. I’ve also run into this error while attempting to import a database using phpMyAdmin. Regardless of how you manage to trigger this fatal PHP error, the fix is the same.

A WordPress error message letting us know that the maximum upload file size has been exceeded

This is another issue that can be resolved by making some changes to php.ini.

Head back to php.ini. This time, look for the line that defines the upload_max_filesize. By default, this value is set to 2 megabytes. Increase the value to a number that will accommodate the size of the file or database you are trying to upload. Keep in mind that acceptable values are any number that is a power of two. So acceptable values are powers of two: 2M, 4M, 8M, 16M, 32M, 64M, 128M, and so forth. Use a different value, 20M for example, and Apache will round-down the effective value to the nearest acceptable value, which would be 16M if you were to input 20M.

upload_max_filesize increased to 128M

Before closing php.ini, look for the line that defines post_max_size. This value works hand-in-hand with upload_max_filesize. Increasing one without increasing the other will cause the smaller of the two to be applied as the maximum uploadable file size. Find the line, and use the same value you used for upload_max_filesize.

post_max_size increased to 128M

If you take the time to look carefully at the notes in the php.ini file, you’ll see that for many settings a URL is provided where you can learn more about the setting you’re adjusting. It’s always worth taking a moment to visit the referenced URL. For example, the documentation provided for the post_max_size setting lets us know that the memory_limit value should be at least as large as post_max_size. A quick look at memory_limit reveals that the default value is 128 megabytes. Unless you set a higher limit for post_max_size and upload_max_filesize than 128M, you won’t need to adjust this value.

Problem 3: Fixing Apache Port Conflicts

Another error message that is pretty common to see when working with XAMPP is a notification in the XAMPP control panel that the ports Apache needs to use, ports 443 and 80, are already being used by another application.

A message from the XAMPP control panel letting us know Skype is using ports 443 and 80

In the case of the error message in the image above, this is a pretty easy fix. The offending application is Skype. If you see the same message, close Skype completely and restart XAMPP to solve the problem. Skype is a frequent-flier on the port-blocking scene and pretty easy to identify and remediate. Unfortunately, things aren’t always so simple. Other things you can try if quitting Skype doesn’t fix the issue are:

  • Stop World Wide Web Publishing Service, a utility application pre-installed on many Windows computers. To stop it, open up Administrative Tools > Services in the Windows Control Panel, look for the application, select it, and click Stop.
  • Use Windows Firewall to force the ports to remain unblocked. Do this by opening the Windows Control Panel and navigating to Windows Firewall > Advanced Settings. Then add a new inbound rule forcing ports 80 and 443 to remain unblocked.

These two fixes are covered in greater detail in our previous tutorial on setting up XAMPP so we won’t rehash all of the details here. Instead, check out that tutorial to try those port-clearing fixes.

Sometimes unblocking port 80 can be particularly challenging. Or it may be the case that you need whatever application is using port 80 to keep using it. In that can, you can configure XAMPP to work over port 8080 rather than port 80.

To make this change, open the XAMPP control panel but don’t start MySQL or Apache. Instead, click on Configure in the Apache row and select the Apache (httpd.conf) option.

XAMPP control panel, selecting Config and then Apache httpd.conf
Select Config and Apache httpd.conf

Alternatively, you can navigate to C:xamppapacheconfhttpd.conf to open the file.

Once you have the file open, locate the line that says Listen 80 and change it to Listen 8080. Next, find the line that says ServerName localhost:80 and change that value to ServerName localhost:8080. Save the changes and close the file.

With those changes made, restart XAMPP and start up Apache and MySQL. Port 80 should no longer be in use. Instead, you should see Apache now running on ports 443 and 8080.

There are two additional things you have to do to make this change work:

  1. Use http://localhost:8080/ to access all of your XAMPP-powered websites rather than http://locahost/.
  2. If you had already installed any WordPress sites locally prior to changing the port, you will need to update the WP_HOME and WP_SITEURL definitions in wp-config.php manually to reflect the new domain prefix.
Define your site and home url as localhost:8080 in wp-config
Of course, you would use the directory where you’ve installed WordPress locally rather than “yourWordPressSite”.

Problem 4: Unable to Add or Import Additional Menu Items

If your website menus contain more than 90 items you have two problems.

  1. You may want to seriously rethink your website navigation. There aren’t very many websites that have a good reason for having that many menu items.
  2. You’ll find that as you try to add additional menu items you won’t be able to. In addition, if you try to import a WordPress website with existing menus that contain more than 90 items, some of the items will be removed from the menus.

This is one more example of a problem caused by PHP settings contained in the php.ini file. So let’s go ahead and open it back up.

Once you have the file open, look for the line the sets the limit on the max_input_vars.

Screenshot of php.ini showing the max_input_vars definition

The default value for this item is 1000. To determine the value you need to use to accommodate all of your planned mega-monster-menu items take the number of menu items you need, multiply it by 11, and add 9 to the product. So, if you need to accommodate 120 menu items, you will need to increase the limit to at least 1329 (120 * 11 + 9).

If you’re curious, a very good explanation of why this formula works is available on StackOverflow.

After updating this value to reflect the number of planned menu items, save the file, close it, and restart Apache. Until Apache has restarted the changes will not take effect.

Wrapping Up

XAMPP provides an easy way to run a local server environment on your Windows machine, allowing you to test and develop locally, rather than installing WordPress on a live site. It will also save you a bunch of time since you won’t have to install and uninstall WordPress each time you test themes and plugins.

But working with XAMPP can be a bit of a headache sometimes (just search Google for how many times people have searched for fixes to issues!). However, doing so also gives you the opportunity to learn more about WordPress, Apache, phpMyAdmin, and PHP than you might ever learn if you limited all of your development to a live web server.

What other challenges have you run into while working with XAMPP and WordPress? How did you solve them?

Tags: