WP-DBManager

Hospedagem WordPress com plugin WP-DBManager

Onde devo hospedar o plugin WP-DBManager?

Este plugin pode ser hospedado em qualquer servidor que possua WordPress configurado. Recomendamos fortemente escolher um provedor de hospedagem de confiança, com servidores otimizados para WordPress, como o serviço de hospedagem de sites da MCO2.

Hospedando o plugin WP-DBManager em um provedor confiável

A MCO2, além de instalar o WordPress na versão mais atualizada para seus clientes, disponibiliza o WP SafePress, um sistema singular que assegura e otimiza seu site conjuntamente.

Por que a Hospedagem WordPress funciona melhor na MCO2?

A Hospedagem WordPress funciona melhor pois a MCO2 possui servidores otimizados para WordPress. A instalação de WordPress é diferente de uma instalação trivial, pois habilita imediatamente recursos como otimização automática de imagens e fotos, proteção da página de login, bloqueio de atividades maliciosas diretamente no firewall, cache avançado e HTTPS ativado por padrão. São recursos que potencializam seu WordPress para a máxima segurança e o máximo desempenho.

WP-DBManager looks after the database behind your site: it backs it up, restores it, optimizes and repairs it, empties or drops tables and runs queries you write, all from wp-admin rather than from a shell or phpMyAdmin. Backups, optimization and repair can be left to run on a schedule, and the backup can be emailed to you when it finishes.

Doações

Eu passo a maior parte do meu tempo livre na criação, atualização, manutenção e suporte desses plugins, se você realmente ama meus plugins e pode me enviar alguns dólares, eu realmente aprecio isso. Mas do contrário, sinta-se livre para usá-los sem quaisquer obrigações.

Usage

Securing The Backup Folder

A database backup contains everything, including your users table. Anyone who can guess a backup file name can download the lot, so the folder must not be served over HTTP.

The reliable option, on any server: set Path To Backup under WP-Admin -> Database -> Settings to a folder outside your web root, for example /var/www/example.com/backup-db when WordPress lives in /var/www/example.com/public_html. Nothing served, nothing to configure.

If the folder has to stay inside the web root:

• Apache — move htaccess.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/.htaccess
• IIS — move Web.config.txt from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/Web.config
• nginx — nginx does not read .htaccess files, so the file above does nothing. Add this to your server block and reload nginx:

location ^~ /wp-content/backup-db/ { deny all; }

Move index.php from Folder: wp-content/plugins/wp-dbmanager to Folder: wp-content/backup-db/index.php as well, so the folder cannot be listed.

The Backup DB page requests a file from the folder and reports what the server actually returns, so you can confirm the folder is closed rather than assume it.

WP-CLI

wp dbmanager tables
wp dbmanager backups
wp dbmanager backup --yes
wp dbmanager backup --no-gzip --yes
wp dbmanager restore <file> --yes
wp dbmanager delete <file>... --yes
wp dbmanager email <file> --to=ops@example.org --yes
wp dbmanager optimize --all --yes
wp dbmanager repair wp_options --yes
wp dbmanager empty <table>... --yes
wp dbmanager drop <table>... --yes

Everything that changes anything asks first, so a script has to pass --yes. That includes backup, which deletes the oldest backups to stay inside Maximum Backup Files, and email, because a dump holds your users table and a sent message cannot be recalled. tables and backups only read, and take a --format of table, csv, json, yaml, count or ids; their sizes are in bytes rather than the KiB and MiB the screens print, because a shell is better at arithmetic than at parsing 1.2 MiB.

optimize and `repair` take table names or `--all`. `empty` and `drop` take names only: emptying or dropping every table in a database is not maintenance, and the screen at least shows you the list before you tick it.

There is no run subcommand. WP-CLI already ships wp db query, which reaches the same database through the same client, so the Run SQL Query screen has no command counterpart. That screen is unchanged and still works.

wp dbmanager checks no capability. WP-CLI has no logged-in user unless you ask for one with `--user`, and whoever can run it can already read the credentials in `wp-config.php`, so a check would refuse every scheduled backup script while protecting nothing. The `install_plugins` gate on the admin screens is unchanged.