This guide aims to provide a step-by-step process for setting up WordPress and Magento projects in a local environment, utilizing Docker or LocalWP.
- Docker Desktop: Ensure Docker Desktop is installed on your machine. Download Docker Desktop.
- LocalWP: For WordPress-specific projects, LocalWP is a more user-friendly option. Download LocalWP.
- Basic Command Line Knowledge: Familiarity with terminal or command prompt commands is required.
- Code Editor: Use any code editor like Visual Studio Code, Sublime Text, etc.
- Setting up projects via Docker
- Setting up WordPress projects via Docker
- Useful docker commands
- Troubleshooting Docker WordPress setup
- Setting up Magento 1 projects via Docker
- Troubleshooting Docker Magento 1 setup
- Setting up Magento 2 projects via Docker
- Troubleshooting Docker Magento 2 setup
- No products is showing on frontend
- Cached page, no new changes are showing
- I've changed something inside
app/code/
directory but it's not showing - Container run out of memory when performing CLI commands
- Apache throws error 500
- Executor failed running
/bin/sh -c php -d memory_limit=-1 bin/magento setup:upgrade
ondcu
- Setting up WordPress projects via LocalWP
- Debugging in WordPress
- Debugging in Magento 1.x
- Debugging in Magento 2.x
- How to use staging or production database in your local setup
If you are not already familiar with Docker, it's recommended to start with the Docker Getting Started documentation. Key areas to pay special attention to include:
- Overview of Docker concepts: Understanding the fundamental concepts such as images, containers, and Dockerfiles.
- Setting up your Docker environment: Learn how to install and configure Docker on your specific operating system.
- Building and running your first container: This section provides practical experience in building and running Docker containers, which is crucial for setting up your development environment.
- Docker Compose: Understanding Docker Compose is essential for managing multi-container applications, like those you'll be creating for WordPress and Magento.
In the instructions below, we will be using variable such as project_name
or database_name
, these should be replaced by the actual project or database names. database_name
variable will be the name of the demo database dump, which can be found in the root of the project. For example this could look something like pickles.sql.zip
, in such case you would be using pickles
instead of database_name
in the commands below.
Have in mind that these setups are based on alrady existing preconfigured Docker files. Always make sure to check project readme file for more specific instructions.
-
Clone project from the GitHub repo
-
Unzip demo database dump:
unzip -o database_name.sql.zip > database_name.sql rm -r __MACOSX
-
All database credentials and wp-config.php data are stored in the
.env
file. Run:cp .env.example .env
-
Go into project root directory and run the containers with:
docker-compose build && docker-compose up -d
-
If you haven't already, you will have to add an entry to hosts file like this:
127.0.0.1 project_name.local ::1 project_name.local
An additional container is included that lets you use the wp-cli
app without having to install it on your local machine.
You can now visit your site(http://project_name.local), or go to phpMyAdmin dashboard(http://project_name.local:8000)
To use these commands we will first create aliases for them. Creating or adding an alias on a Mac involves modifying your shell's configuration file. The process can slightly vary depending on the shell you are using (e.g., Bash or Zsh, with Zsh being the default on newer macOS versions). If you are unsure which shell you are using, type echo $SHELL
in your Terminal.
Next step vould be to open the shell from the terminal with editors such as vim
or nano
. In this case we will use vim
:
-
Type
vim ~/.zshrc
in the Terminal, to open the.zshrc
file. Then pressi
to enter theINSERT
mode -
We will be adding the aliases and two Docker related functions from the snipet below
alias docker-compose="docker compose" alias dcb="docker-compose build" alias dcu="docker-compose up" alias dcd="docker-compose down" alias dcl="docker-compose exec --user $(id -u):$(id -g) web /bin/bash" alias dcdebug="docker-compose down && docker-compose run --service-ports web" alias dclc="dockerlogin" alias dwp="docker_wpcli" docker_wpcli() { declare ARGS # if CWD is not WordPress project, exit if ! [[ -d ./wp-includes && -d ./wp-admin && -d ./wp-content ]]; then echo 'Not in WordPress project.' return 1 fi # If WordPress and DB are not running, exit CWD=${PWD##*/} CONTAINERS_ACTIVE=$(docker ps | grep $CWD | wc -l) if [ $CONTAINERS_ACTIVE -lt 2 ]; then echo 'Start WordPress and Database containers first.' return 1 fi # if container already exists, recreate it COUNT=$(docker ps -a | grep wp_cli | wc -l) if [ $COUNT -gt 0 ]; then echo Recreating wp_cli container.. docker rm wp_cli fi # If no arguments are passed, display wp info if [ $# -eq 0 ]; then ARGS="--info" else ARGS=("$@") fi docker-compose run --name wp_cli --rm wp_cli "${ARGS[@]}" } dockerlogin() { if [ -n "$1" ] then docker-compose exec --user $(id -u):$(id -g) $1 /bin/bash fi }
-
Press
esc
on the keyboard to exit theINSERT
mode, and then type:wq
to save the changes and exit from the file.
After adding the alias and reloading the shell configuration, you can test it by typing the alias in the Terminal. For example, if you added alias dps='docker ps'
, just type dps
and it should execute docker ps
.
dcl # Calls dockerlogin function
Or if you don't have an alias set:
docker-compose exec <service> /bin/bash # services: web, db, phpmyadmin, etc..
dwp plugin list
dwp plugin update <plugin> # paste plugin name from the list
Or if you don't have an alias set:
docker-compose run wp_cli --rm --name wp_cli plugin/theme update
dwp theme activate <theme>
dwp theme deactivate <theme>
dwp db export dump.sql
dwp db import dump.sql
For more information about wp-cli
, read WP-CLI documentation.
Docker commands and scenarios that could be useful for someone managing WordPress environments with Docker. These examples cover various common tasks and troubleshooting scenarios.
If you need to import a database into a WordPress container, you can use the following commands:
# List running containers to find the database container ID
docker ps
# Import a database using the container ID
docker exec -i CONTAINER_ID mysql -uUSERNAME -pPASSWORD DATABASE_NAME < your_database.sql
# Or, using docker-compose
docker-compose exec -T DB_SERVICE_NAME mysql -uUSERNAME -pPASSWORD DATABASE_NAME < your_database.sql
To export a database from your Docker container, use these commands:
# Run Docker container in detached mode
docker-compose up -d
# List containers to find the database container ID
docker ps
# Export the database
docker exec CONTAINER_ID /usr/bin/mysqldump -u root --password=PASSWORD DATABASE_NAME > exported_db.sql
# Or, using docker-compose
docker-compose exec -T DB_SERVICE_NAME /usr/bin/mysqldump -u root --password=PASSWORD DATABASE_NAME > exported_db.sql
To check the logs of your WordPress container:
# Using Docker
docker logs CONTAINER_ID
# Using docker-compose
docker-compose logs SERVICE_NAME
If you need to restart your containers:
# Restart all containers using Docker Compose
docker-compose restart
# Restart a specific service
docker-compose restart SERVICE_NAME
To access the MySQL shell within your Docker container:
# Using Docker
docker exec -it CONTAINER_ID mysql -uUSERNAME -pPASSWORD
# Using docker-compose
docker-compose exec DB_SERVICE_NAME mysql -uUSERNAME -pPASSWORD
To flush the cache in WordPress:
# Flush cache using WP CLI
docker exec CONTAINER_ID wp cache flush
To fix file permissions in a WordPress container:
# Adjust permissions for the WordPress directory
docker exec CONTAINER_ID chown -R www-data:www-data /var/www/html
Replace CONTAINER_ID
, DB_SERVICE_NAME
, USERNAME
, PASSWORD
, DATABASE_NAME
, and your_database.sql
with your actual container ID, service name, database username, password, database name, and SQL file name. These commands assume that you have a running Docker environment with Docker Compose and that your docker-compose.yml
file is set up correctly for your WordPress and database services.
-
Clone the project from the GitHub repo
-
If you haven't already, you will have to add an entry to hosts file. To open the file run:
sudo vim /etc/hosts
At the end of the file add:
127.0.1.1 project_name.local
-
Unzip demo database dump:
unzip -o database_name.sql.zip > database_name.sql
-
Go into project root directory and run the containers with:
docker-compose up -d
-
Update local.xml(
app/etc/local.xml
) file with these credentials:<username><![CDATA[magento]]></username> <password><![CDATA[secret]]></password> <dbname><![CDATA[magento]]></dbname>
-
If you have any issues or errors when loading
project_name.local
, delete the cache located in the/var/cache
folder in project root. Build always takes time so be patient! Magento cache in the admin is probably disabled, which will slow down projects in the local environment.
Docker commands and scenarios that could be useful for someone managing Magento 1 environments with Docker. These examples cover various common tasks and troubleshooting scenarios.
Logs are often the first place to look when something goes wrong.
# View logs of a specific container
docker logs CONTAINER_ID
# Follow the logs in real-time
docker logs -f CONTAINER_ID
Accessing the shell of your container can be invaluable for direct inspection and troubleshooting.
# Access shell of a specific container
docker exec -it CONTAINER_ID /bin/bash
Docker's inspect command provides detailed information about a container's configuration and state.
# Inspect a specific container
docker inspect CONTAINER_ID
Clearing the Magento cache can resolve many issues.
# Clear Magento cache from the container
docker exec CONTAINER_ID rm -rf /var/www/html/var/cache/*
Ensure that your application can connect to the database.
# Access MySQL shell
docker exec -it DB_CONTAINER_ID mysql -uUSERNAME -pPASSWORD
# Check if you can connect to the database from your Magento container
docker exec CONTAINER_ID mysql -hDB_HOST -uUSERNAME -pPASSWORD -e "SHOW DATABASES;"
Sometimes, a simple restart can fix a problem.
# Restart a specific container
docker restart CONTAINER_ID
# Restart all containers in docker-compose
docker-compose restart
Incorrect file permissions can cause errors, especially in a Magento environment.
# Check file permissions
docker exec CONTAINER_ID ls -l /var/www/html
# Correct file permissions
docker exec CONTAINER_ID chmod -R 755 /var/www/html
docker exec CONTAINER_ID chown -R www-data:www-data /var/www/html
Replace CONTAINER_ID
, DB_SERVICE_NAME
, USERNAME
, PASSWORD
, DATABASE_NAME
, and your_database.sql
with your actual container ID, service name, database username, password, database name, and SQL file name. These commands assume that you have a running Docker environment with Docker Compose and that your docker-compose.yml
file is set up correctly for your WordPress and database services.
-
Clone the project from the GitHub repo
-
If you haven't already, you will have to add an entry to hosts file. To open the file run:
sudo vim /etc/hosts
At the end of the file add:
127.0.0.1 project_name.local ::1 project_name.local
-
Rename
package.json.sample
topackage.json
. You can do this with:cp package.json.sample package.json
-
Rename
app/etc/env_local.php
toapp/etc/env.php
. You can do this with:cp app/etc/env_local.php app/etc/env.php
-
If there is a WordPress in combination with Magento
-
Rename
wp/wp-config_local.php
towp/wp-config.php
-
Change DB_HOST (wp/wp-config) & host (app/etc/env.php) IP address if different then
172.19.0.2
is assigned to your container. To check IP addresses of containers run the following command:docker inspect -f '{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)
-
-
Go into project root directory and run the containers with:
docker-compose up -d
-
Unzip project demo database dumb (
database_name.sql.zip
) and import the database once container is set:unzip -o database_name.sql.zip > database_name.sql
docker exec -i DB_CONTAINER mysql -uUSER -pPASSWORD magento < database_name.sql
You can run docker ps
to see containers info such as DB_CONTAINER
name.
- Once done, you can visit the site at
project_name.local
Run reindexer from inside the container bin/magento indexer:reindex
Clear the cache bin/magento cache:clean
Sometimes, you might also need to clear the generated content: rm -rf var/cache/* var/page_cache/* generated/code/*
.
Run setup upgrade script bin/magento setup:upgrade
Also, consider running bin/magento setup:di:compile
if you're working with dependency injection or plugins.
Add following before command then run php -dmemory_limit=2G
SSH into web container and run a2enmod rewrite
then restart apache2:
# Display a list of all active containers. Look for the container that is running your web server and note its CONTAINER ID or NAME.
docker ps
# SSH into the Docker Container
docker exec -it [CONTAINER_ID_OR_NAME] /bin/bash
# Restart Apache
a2enmod rewrite
-
Comment out these lines in Dockerfile
php -d memory_limit=-1 bin/magento setup:upgrade php -d memory_limit=-1 bin/magento cache:clean
-
Start the container
docker-compose up
-
SSH into web container and run
composer install --ignore-platform-reqs
To set WordPress projects locally in a more user friendly way you can use LocalWP.
-
Download the Local WP to your computer
-
Add new local project with default settings and
project_name
, and set site domain toproject_name.local
-
Clone this project to your
Sites
folder, and from there run this command:rsync -avzhp --progress --exclude 'wp-config.php' . ~/Local\ Sites/project_name/app/public/
Alternatively you can delete the WordPress files added by Local WP, and clone this project in that place(~/Local Sites/project_name/app/public), and then update the wp-config.php file with these:
'DB_NAME': 'local' 'DB_USER': 'root' 'DB_PASSWORD': 'root'
-
Import demo database from the project. But to do so first unzip the database:
unzip -o database_name.sql.zip > database_name.sql rm -r __MACOSX
Import the database included in the project using the Adminer tool provided in Local. (This is a simple phpMyAdmin alternative.). Or if there are any issues with this you can open the site SSH shell and type:
mysql -uroot -proot local < database_name.sql
In case if there are issues with loading the database, you can try to delete and recreate the local wp database from the site shell. First login to mysql with:
mysql -uroot -proot
Then delete and recreate WordPress local database, with:
drop database local; create database local; exit
-
Sort out the SSL certificate trust issues by following this guide
-
Test the site by opening WP Admin from Local.
-
Happy coding!
To use the WP CLI in your project set with Local WP, you will need to open the SSH shell, and from there you can use WP CLI commands. Some useful commands:
-
Export the local database
wp db export backup.sql
-
Import a local database
wp db import backup.sql
-
Search and Replace in project database
# Useful if you have loaded the database from staging or production wp search-replace '.com' '.local' wp search-replace '.websitetotal.com' '.local'
-
Ggenerate
.pot
file from theme or plugin folder# Make sure this one is run from the correct folder wp i18n make-pot . languages/pot_file_name.pot
-
List all the plugins
wp plugin list
-
Update the plugin
wp plugin update plugin_name
-
Activate the plugin
wp plugin activate plugin_name
-
Deactivate the plugin
wp plugin deactivate plugin_name
-
Show only a list of all active plugins which have updates available
wp plugin list --field=name --status=active --update=available
-
List all users
wp user list
-
List admin users
wp user list --role=administrator
-
Create a new administrator user
wp user create admin name@stuntcoders.com --role=administrator --user_pass=sc123123
-
Update existing administrator user password
wp user update USER_ID --user_pass=sc123123
-
Delete the user and reassign that user’s posts to any other user
wp user delete USER_ID --reassign=OTHER_USER_ID
-
Regenerate all media attachments. Useful when changing image sizes
wp media regenerate
-
Flushe the WordPress site cache
wp cache flush
-
List all meta data associated with the specified post
wp post meta list POST_ID --format=table
-
Get a Specific Meta Field for a Post
wp post meta get POST_ID META_KEY
-
List All Meta Data for a User
wp user meta list USER_ID --format=table
-
Get a Specific Meta Field for a User
wp user meta get USER_ID META_KEY
-
List Rewrite Rules
wp rewrite list --format=table
-
Export content to an XML file
wp export --dir=/path/to/export --user=author --start_date=2021-01-01 --end_date=2021-12-31
Debugging in WordPress is a crucial skill for developers, as it helps identify and resolve issues within themes, plugins, or the WordPress core itself. Here are some general rules and advice for debugging in WordPress:
- Enable WP_DEBUG:
-
Edit the
wp-config.php
file in your WordPress root directory. -
Set
WP_DEBUG
totrue
. This enables the debug mode in WordPress.define('WP_DEBUG', true);
-
This will start displaying PHP errors, notices, and warnings.
-
- Log Errors to a File:
-
In
wp-config.php
, you can also enableWP_DEBUG_LOG
to save these errors to adebug.log
file within thewp-content
directory.define('WP_DEBUG_LOG', true);
-
- Display Errors on the Page:
-
To display errors directly on the web page (useful in a local development environment), set
WP_DEBUG_DISPLAY
totrue
.define('WP_DEBUG_DISPLAY', true);
-
In a production environment, it's recommended to set this to
false
to prevent visitors from seeing errors.
-
Usual combination will look, something like this:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
This will ensure that WordPress will save errors to wp-content/debug.log
, and no errors will be shown on the web page. Regularly check this file for any new warnings or errors.
- Query Monitor:
- Install the Query Monitor plugin. It provides a detailed analysis of database queries, hooks, conditionals, HTTP requests, redirects, and more.
- It's particularly useful for identifying slow queries or hooks that may be affecting performance.
- More in depth guide, can be found in this article.
- WP Crontrol:
- WP Crontrol plugin allows you to view and control what's happening in the WP-Cron system. It's useful for debugging issues with scheduled events in WordPress.
- User Switching:
- User Switching plugin is a handy tool for developers and administrators. It allows you to quickly switch between user accounts in WordPress at the click of a button. It's great for testing different user roles and capabilities.
Have in mind that these plugins in most cases should be installed only when needed, and removed after there is no more need for them.
- Using
error_log()
:-
You can use the
error_log()
function in PHP to add custom error messages or variable values to the WordPressdebug.log
file.error_log( print_r( $your_variable, true ) );
-
This is useful for tracking the values of variables at specific points in your code.
-
- Var Dump and Print_R:
-
Use
var_dump()
orprint_r()
to output the contents of a variable, usually for debugging purposes directly on the web page.var_dump( $your_variable ); print_r( $your_variable );
-
Have in mind that
pring_r()
displays information about a variable in a way that's readable by humans, which means that output will be better formatted, and the data we are trying to see will be presented in a more readable format. We can do something similar withvar_dump()
, by using something like this:echo '<pre>' , var_dump( $your_variable ) , '</pre>';
-
Remember to remove or comment out these calls before pushing your code to production.
-
- Deactivate All Plugins:
- If you're encountering issues, try deactivating all plugins. If the issue resolves, reactivate them one by one to identify the culprit.
- Switch to a Default Theme:
- Temporarily switch to a default WordPress theme (like Twenty Twenty-One) to see if the issue is theme-related.
- Xdebug:
- Using Xdebug for profiling is a powerful way to identify performance bottlenecks in your PHP code, including WordPress and other web applications. Xdebug is a PHP extension that provides debugging and profiling capabilities. If you are using LocalWP for setting up your local WP projects, you can easily enable or disable this extension with one click.
- You can find more about how to use and set this extension on LocalWP, in this user guide: Xdebug within Local
- Have in mind that Xdebug can make your site really slow, so enable this extension only if you need it. Since Xdebug hooks into every part of PHP, it can cause complex sites to run slower than it would without Xdebug. If you are not able to disable Xdebug directly from the LocalWP user interface, to disable it follow these instructions. To make LocalWP even faster, you can update
max_execution_time
,max_input_time
,max_input_vars
andmemory_limit
in the same file mentioned in the instructions above.
- Mailhog:
- To make debugging easier, LocalWP uses Mailhog modules to log all the emails for use in debugging and troubleshooting. You don't need an extra mail server to test the mail functionality.
- To view the email logs, you can go to the
Utilities
tab, then selectOpen Mailhog
. You can see email logs. - You can find more about Mailhog in this Kinsta article.
In Magento 1.x, the full error display on frontend is disabled by default.
In cases when some fatal error happens, we will see something like this:
There has been an error processing your request
Exception printing is disabled by default for security reasons.
Error log record number: 912455321715
You can see in the message above that error log record number for this error message is: 912455321715
.
To see the full error you need to go to your project root
, and then to the var/report
folder, and find a file with the name which is equal to the error log record number. So in our case, we would have something like this in our project root:
var/
|__report/
| |__ 912455321715
| |.. ...
We can just rename local.xml.sample
which is inside our project root, errors
folder. You just need to:
- Rename
local.xml.sample
tolocal.xml
- Refresh Cache from your Magento Admin (System -> Cache Management).
After this you will see error messages directly on you web page.
You can edit the index.php
file in your project root
.
-
Open the file
-
Go to this part:
if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) { Mage::setIsDeveloperMode(true); } #ini_set('display_errors', 1);
-
Set the
SERVER
variableMAGE_IS_DEVELOPER_MODE
astrue
-
Set PHP error reporting as
E_ALL
-
Enable PHP error display
$_SERVER['MAGE_IS_DEVELOPER_MODE'] = true; error_reporting(E_ALL); if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE'])) { Mage::setIsDeveloperMode(true); } ini_set('display_errors', 1);
In Magento 2.x, just like in the case of Magento 1.x, the full error display on frontend is disabled by default.
In cases when some fatal error happens, we will see something like this:
There has been an error processing your request
Exception printing is disabled by default for security reasons.
Error log record number: 912455321715
You can see in the message above that error log record number for this error message is: 912455321715
.
To see the full error you need to go to your project root
, and then to the var/report
folder, and find a file with the name which is equal to the error log record number. So in our case, we would have something like this in our project root:
var/
|__report/
| |__ 912455321715
| |.. ...
We can just rename local.xml.sample
which is inside our project root, pub/errors
folder. You just need to:
- Rename
local.xml.sample
tolocal.xml
- Refresh Cache from your Magento Admin (System -> Tools -> Cache Management).
After this you will see error messages directly on you web page.
-
Go to your project
root
directory -
Got to the
app
folder and openbootstrap.php
file -
At the beginning of the file, you will see the following line of code:
#ini_set('display_errors', 1);
-
Change that into this:
error_reporting(E_ALL); ini_set('display_errors', 1);
-
Save the file, and go to your project
root
directory and run:php bin/magento deploy:mode:set developer
-
Check the current deploy mode with the following command:
php bin/magento deploy:mode:show
-
Clear the Cache
php bin/magento cache:clean
In some cases you might encounter situations that you do not have all the necessary data in the project demo database dump, or you will have to quickly reproduce the issues which are noticed on the staging or production servers, so in such cases you will have to use a database from staging or production website in your local setup.
First prerequisite here is that you actually have the access to the staging or production server. If not, this guide will not be useful to you, and you will have to ask from someone else to provide the database for you.
-
First SSH to staging or production server. From the terminal type this:
ssh user_name@server_address
Replace
user_name
with your actualuser_name
on the server andserver_address
with the server's IP address or domain name. You can usually see the appropriateuser_name
andserver_address
, in the deployment scripts used on the project (Fabric, Capistrano...). For example, to connect to a server with the IP192.168.1.100
as userjohn
, you would use:ssh john@192.168.1.100
-
Navigate to WordPress Directory. This is typically in a directory like
/var/www/yourwebsite
or/public_html
. And can also be seen as thedeploy_path
, in the deployment scripts used on the project. It should look something like this:cd /home/user_name/www #Or cd /home/user_name/web/server_address/
-
Locate Database Credentials. These are stored in the
wp-config.php
file in your WordPress directory. You can usevim
ornano
to open this file directly on the server:vim wp-config.php
It should show you something like this:
define('DB_NAME', 'your_db_name'); define('DB_USER', 'your_db_username'); define('DB_PASSWORD', 'your_db_password');
-
Dump the Database. Now, use the
mysqldump
command to dump the database. Replaceyour_db_name
,your_db_username
, andyour_db_password
with the actual values you found in thewp-config.php
file. Also, replaceyour_backup.sql
with the desired name for your backup file.mysqldump -u your_db_username -p your_db_password your_db_name > your_backup.sql
In most cases you will be able to just do this:
mysqldump -uroot your_db_name > your_backup.sql
If you can login to
mysql
with just-uroot
, then you can check the database name directly there, and skip thewp-config.php
check:mysql -uroot show databases; exit;
To download the database dump from your server to your local machine, you can use scp
(secure copy), which is a part of the SSH suite of tools. scp
allows files to be copied to, from, or between different hosts. It uses the same authentication and provides the same security as SSH.
-
Basic SCP Command:
scp username@your_server_ip:/path/to/your_backup.sql /local/directory
Replace
username
with your SSHusername
,your_server_ip
with theIP
address orhostname
of your server,/path/to/your_backup.sql
with the full path to the database dump file on your server, and/local/directory
with the path to the directory on your local machine where you want to save the file.Suppose your username is
john
, your server'sIP
address is192.168.1.100
, your database dump is located at/var/www/yourwebsite/your_backup.sql
, and you want to download it to yourdesktop
. The command would look like this:scp john@192.168.1.100:/var/www/yourwebsite/your_backup.sql ~/Desktop/
Once you have downloaded the database dump from the server, you should delete this file from the server. We can do this with:
rm your_backup.sql
When moving a database from a live server to a local setup for Magento and WordPress, you often need to perform a search and replace operation. This is because these platforms store absolute URLs (including the domain name) and file paths in the database, which will differ between your live and local environments.
For WordPress projects we can do it with WP CLI. Import the database and then run this:
wp search-replace 'oldurl.com' 'newurl.local'
wp search-replace 'https' 'http'
https
to http
step is unnecessary if you have SSL certificates set.
Magento stores base URLs in its database, so you'll need to update them for your local environment.
-
First import the database:
mysql -u username -p database_name < database_dump.sql
-
Access Your Database using a tool like phpMyAdmin or a MySQL client.
-
Run SQL Queries to update the base URLs. The exact queries depend on your Magento version, but they generally look like this:
UPDATE core_config_data SET value = 'http://yourlocaldomain/' WHERE path = 'web/unsecure/base_url'; UPDATE core_config_data SET value = 'https://yourlocaldomain/' WHERE path = 'web/secure/base_url';
Replace
http://yourlocaldomain/
andhttps://yourlocaldomain/
with your local environment's URL. -
Clear the Cache after making these changes, either via the admin panel or by deleting the cache files from the file system.
-
-
Alternatively you can do this from the command line:
-
Access mysql using this command
mysql -u username -p password
Replace
username
with your mysql user andpassword
with your database password. For example:mysql -uroot -p123456
-
Select the Database:
USE your_database_name;
Replace
your_database_name
with the actual name of your database. -
Run your update Queries:
UPDATE core_config_data SET value = 'http://newurl.dev/' WHERE path = 'web/unsecure/base_url'; UPDATE core_config_data SET value = 'https://newurl.dev/' WHERE path = 'web/secure/base_url';
-
Exit MySQL:
exit
-
Clear Cache:
After updating the URLs, you need to clear the Magento cache to ensure the changes take effect.
- If you have access to the Magento admin panel, navigate to System > Cache Management, and clear the cache.
- Alternatively, you can manually clear the cache by deleting the contents of the
var/cache
directory in your Magento installation.
For Magento 2, you might need to reindex after making changes to the database.
php bin/magento indexer:reindex
-
Finally, test your site to ensure that the base URLs have been updated correctly and that the site is functioning as expected.
In some cases you will not be able to update a plugin in your local environment for example, but we can update the same plugin on our staging or production server, and then we can rsync that with our local.
To do this we can use a command like this one:
rsync -av -e ssh john@192.168.1.100:PATH_TO_YOUR_ROOT_DIRECTORY/wp-content/plugins/PLUGIN_FOLDER_NAME ~/Local\ Sites/PROJECT_NAME/app/public/wp-content/plugins
Make sure that:
- Remote Path is correct, you can check this path in our deployment scripts.
- Adjust the Local Path Escaping if necessary. For example here we have
Local\ Sites
but in some cases on the shell you're using, you might need the double backslash like this:Local\\ Sites