phpMyAdmin Locally on Windows

Local phpMyAdmin is needed before running a script installer: create a database and user, then import a dump during migration. The mysql CLI is also fine, but a browser is faster for most Windows tasks.

In the MicroServer stack, phpMyAdmin is usually available with the environment. If you use another local server, install phpMyAdmin as a separate host or subfolder, not mixed with the client script files.

Before script installation

1. Make sure MariaDB/MySQL is running on 127.0.0.1:3306.
2. Open phpMyAdmin and log in, often as root or as the stack documentation account.
3. Create a database with utf8mb4_unicode_ci or utf8mb4_general_ci collation.
4. Create a user and grant all privileges on this database, not on *.* unless needed.
5. Save database name, login, and password for the installer form.

Next step: script installation. Host in the form: 127.0.0.1.

utf8mb4, not "just utf8"

Old MySQL utf8 is three bytes. Emoji and some characters are cut. Create utf8mb4 immediately. If the database is already latin1, it is easier to recreate it empty before installation than repair it after data appears.

Product requirements: PHP and MySQL.

Dump import

Use the Import tab and select the .sql file. PHP upload limits may cut a large dump; then increase upload_max_filesize / post_max_size or import through CLI:

mysql -u user -p dbname < dump.sql

Full database migration to another server: dump migration. Whole-site migration: script migration.

Before risky experiments, export: backup.

Typical login errors

• Access denied: wrong root/user password or the wrong service.
• Cannot connect to server: MySQL is not running or the port is occupied by another stack such as OpenServer/XAMPP.
• Two phpMyAdmin instances from different builds confuse cookies; use one.

Installer connection error explanations: database error.

Project user

Many people work locally as root. For production habit, create board_user only for the board database. Then prefixes and separate passwords on Beget/Timeweb will not be surprising.

Connection to *.loc hosts

The site lives in project.loc; the database can have any name, though matching names reduce confusion. Hosts: virtual host, stack: MicroServer.

If the script returns 500 after import, check whether config picked up the new credentials: 500 error.

Export for deployment

Quick export, data only, or structure plus data: for hosting migration you need a full dump with structure. Options such as DISABLE KEYS are usually not critical for our sizes. The main thing is that the file is complete and not cut by timeout.

On production hosting, phpMyAdmin in the panel works the same way: create database, import, write config. A local practice run saves nerves on the live account.

Create a user step by step

In phpMyAdmin, use User accounts / Privileges. Create a user with a password; local host is usually localhost or %, and on Windows with MariaDB often localhost/127.0.0.1. Grant on dbname.*, not the entire server.

In the script installer, host 127.0.0.1 is sometimes more stable than localhost because of sockets. If you catch a strange 2002, switch the host in config. Details: database error.

Operations you actually need

• Create or delete a database.
• Export/import SQL.
• Run one-time SQL from a support ticket, carefully and on a copy.
• Check table sizes if disk usage grows.
• Verify table collation after a bad import.

You do not need to "optimize everything" daily through phpMyAdmin. Do not edit serialized option strings by hand; you will break serialization lengths and get a white screen.

Interrupted import

Symptoms: some tables exist, the installer complains that tables already exist, or the site fails on a missing table. Solution: drop the database, create an empty utf8mb4 database, then import through CLI or raise limits and timeouts.

mysql -u root -p -e "DROP DATABASE IF EXISTS board; CREATE DATABASE board CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p board < dump.sql

After successful import, check the table count visually. Full migration scenario: dump migration, script migration.

Several projects, several databases

Do not put a board and a store into one database "to avoid clutter". Dumps and rollbacks become a lottery. Use clear names: board_loc, shop_loc. Site hosts can be board.loc, shop.loc: virtual host.

Local phpMyAdmin security

On a home PC the risk is lower than on a VDS. Still, do not expose phpMyAdmin to the internet through router port forwarding. On production VDS, put phpMyAdmin behind basic auth / VPN or do not install it; CLI and a tunnel are enough. Firewall: on VDS.

Link with the installer

Most Microscript product installers do not create the database themselves; they expect it to exist. Order: database in phpMyAdmin, files in host, browser. Installation: manual. Charset and PHP requirements: requirements.

If after importing a production dump locally the admin login does not work, you are on a different dump or password cache; phpMyAdmin is not broken. Stack: MicroServer. Backup before risky SQL: backup.

Sometimes phpMyAdmin warns about missing blowfish_secret or a connection without SSL. Locally that is noise. On a production server, unprotected phpMyAdmin is an incident. For daily work with a Microscript script on a VDS, CLI and a tunnel are usually enough; keep phpMyAdmin on local MicroServer. Importing a huge dump through a web interface with a 30-second timeout is a lottery: it may stop halfway and leave you debugging why there are 40 tables instead of 90. Use CLI and dump migration. After a successful import, write the script config and open the site on project.loc: vhost, installation if the database is empty and needs an installer, not migration. Stack: MicroServer. utf8mb4 requirements: PHP/MySQL.