![]() ![]() Debugging is fast and easyĭebugging locally can sometimes be easier than on a hosted site. Whether you’re on a plane, in the park, or anywhere else where Wi-Fi might be spotty, this comes in really handy. Offline codingĪnother huge advantage of using a local development environment is that you can code offline. If you’re using a local WordPress development environment, there are no limits. Most hosting providers have limits on the number of staging sites you can have. It also gets rid of any network latency, so caching isn’t even really needed. If you’re testing locally, this relies on the resources of your computer. If you’re bouncing around testing things, this can be frustrating. However, the result is that sometimes the staging site will be slower than the live site. You have to remember that hosting providers have bills too. Either they have caching turned off for development purposes (this is a good thing when testing) or fewer resources (PHP workers, RAM) than the live site. However, the problem behind many of these is that they are sometimes limited. Many hosting providers include staging sites for free these days. Staging sites are typically slower than testing locally You have existing tools like Local from Flywheel and your classic XAMPP and MAMP solutions.īut why even bother with testing locally? Well, there are a few advantages in my opinion. For many, it’s been a part of their regular workflow for years. The idea of a local WordPress development environment isn’t anything new. In the end, this what my wp-config.php looks like and everything seems to be working now: /** MySQL hostname */Īgain, I’m not sure this was worth writing about, but every time I have to solve a problem in a way that isn’t already on the internet, I figure I might be able to save someone else 30 minutes of pain.Advantages of a local WordPress development environment Since my MAMP version defaults to port 8889, I figured that could be the issue. A few answers suggest changing localhost to a local IP like 127.0.0.1 but that didn’t seem to fully resolve the issue for me, which lead me back to MAMP and MySQL Workbench.īased on the in-depth answers on Stack Overflow, it looks like this PHP class would expect SQL to be running on its default port, which is typically 3306. I didn’t get into the weeds of what is actually happening at the system level, since I really just wanted a cleaner way to start of a new theme. I found a few answers here and here that explain the essence of the issue is that the PHP mysqli_real_connect() class is trying to access the underlying UNIX socket in a way that doesn’t play well with localhost. After checking that everything was running and I hadn’t swapped any ports in MAMP, I went out to Stack Overflow. I had been messing with my local databases all morning, so I figured this was something I had screwed up. ![]() This could mean your host’s database server is down. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `127.0.0.1`. The stack trace of the error started off with something link the following error message kicked out by PHP: PHP Warning: mysqli_real_connect(): (HY000/2002): Connection refused in /path/to/wordpress/wp-includes/wp-db.php on line 1531Īnd then it ended with a friendlier, but a bit less helpful error from WP CLI: Error: Error establishing a database connection. It was easy enough to install, but I got a series of errors after running the following command: wp scaffold _s I decided to play around with WP CLI to scaffold out the theme for a project that we are starting, but ran into a few configuration issues. This will be a short post, but I felt it necessary to do since I had to deal with this is a non-standard way given my situation.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |