O WordPress usa o MySQL, um sistema de gerenciamento de banco de dados de código aberto, para armazenar e recuperar todas as informações do seu site, desde o conteúdo de suas postagens e páginas até seus comentários, nomes de usuário e senhas.
Se você precisa visualizá-lo, pense no banco de dados do seu site como um arquivador e MySQL como a empresa que o fez.
MySQL é uma escolha popular de banco de dados para aplicativos web – Joomla! E Drupal também o usa, e de acordo com a Wikipedia, muitas empresas de alto perfil como Google, Facebook, Twitter, Flickr e YouTube também usam.
Então, como exatamente o MySQL funciona com o WordPress? Neste artigo, eu guiar-te-ei por tudo o que há para saber sobre o MySQL e como ele interage com o WordPress, incluindo a arquitetura do banco de dados, mecanismos de armazenamento, técnicas de otimização e melhores práticas para otimização e gerenciamento de banco de dados.
O que é o MySQL?
O MySQL é um componente central na pilha LAMP de software de aplicação web de código aberto que é usado para criar sites. LAMP significa Linux, Apache, MySQL e PHP. O MySQL também é usado na pilha LEMP, que substitui o Apache pelo Nginx (pronunciado Engine-X).
WordPress usa PHP para armazenar e recuperar dados de bancos de dados MySQL, usando consultas SQL dentro da marcação PHP. Por exemplo, se você é um membro de um site de associação com WordPress, o SQL é usado para efetuar o login, recuperar sua ID de associação exclusiva, verificar se você possui uma associação ativa e garantir que os dados de perfil corretos sejam exibidos na frente -fim.
PHP e SQL funcionam de mãos dadas com o WordPress, permitindo que você crie conteúdo dinâmico com base em muitos fatores diferentes, como suas IDs e funções de usuário. Isso permite que você faça coisas como ocultar ou exibir conteúdo para usuários específicos, como administradores, editores e assinantes. Sem SQL e MySQL, nada disso seria possível.
Plugins e temas também usam seu banco de dados para armazenar dados, como opções e, em seguida, usar SQL na marcação PHP para consultar dinamicamente o banco de dados e exibir conteúdo.
Vale a pena mencionar que se você executar um pequeno site (ou seja, um blog sobre o seu gato), você realmente não precisa mexer com o SQL. É somente quando você trabalha em sites de nível corporativo que ter conhecimento SQL torna-se essencial.
Arquitetura do banco de dados do WordPress ou: Tabelas, Tabelas, Tabelas
Para ajudá-lo a entender como exatamente o WordPress trabalha com o MySQL, vamos passar pelas tabelas das lojas do WordPress em um banco de dados típico.
O WordPress possui um esquema de banco de dados bastante simples e sem complicações. Consiste em 11 tabelas, que são usadas pelos principais componentes do WordPress e não podem ser excluídas ou removidas.
Wp_commentmeta – Armazena os metadados de todos os comentários deixados em suas postagens e páginas do WordPress, incluindo tipos de postagem personalizados.
Wp_comments – Armazena todos os comentários feitos em seu site, incluindo comentários publicados, rascunhos, pendentes e de spam.
Wp_links – Retém todas as informações inseridas no recurso de gerenciador de links do WordPress, isso raramente é usado hoje em dia, com o recurso de link se tornando obsoleto do WordPress 3.5 e escondido por padrão em novas instalações.
Wp_options – Não são apenas todas as opções do WordPress armazenadas nesta tabela, como suas configurações de leitura e discussão, mas é mais comum agora para que os plugins usem wp_options para armazenar configurações salvas em oposição a uma tabela personalizada .
Wp_postsmeta – Como você provavelmente adivinhou , esta tabela armazena todos os metadados associados às suas postagens e páginas.
Wp_posts – Armazena todas as suas postagens , bem como suas páginas e também seus itens de navegação / menu.
Wp_terms – Esta tabela armazena as categorias para postagens, links e as tags.
Wp_term_relationships – As postagens estão associadas a categorias e tags da tabela wp_terms e essa associação é mantida na tabela wp_term_relationships. A associação de links para suas respectivas categorias também é mantida nesta tabela.
Wp_term_taxonomy – Descreve a taxonomia, como uma categoria, link ou tag para as entradas no wp_terms_table .
Wp_usermeta – Armazena os metadados de todos os usuários da tabela wp_users .
Wp_users – Todos os seus usuários estão armazenados nesta tabela. Lembre-se, dados como senhas são serializados.
Bancos de dados multisite são estruturados de forma muito diferente
O banco de dados para uma instalação Multisite é estruturado de forma muito diferente do de um site independente, portanto, se você gerencia um ou outro ou ambos, é importante que você entenda as diferenças para que você possa gerenciar seus sites de forma eficaz.
Wp_blogs – Cada site criado em uma rede Multisite é armazenado nesta tabela.
Wp_blog_versions – Armazena a versão atual do banco de dados de cada site na rede e é usado principalmente no processo de atualização de sua rede. É atualizado à medida que cada site é atualizado.
Wp_registration_log – Registra o usuário admin cria quando cada novo site está registrado.
Wp_site – Esta tabela contém o endereço principal do site.
Wp_sitemeta – Cada site possui dados do site; Esta tabela armazena os dados do site, incluindo várias opções, incluindo o administrador do site.
Wp_users – Contém todos os usuários, enquanto este campo também é usado na instalação de um único site. Inclui dois campos extras / linhas de spam e excluídos.
Wp_usermeta – Ao usar o Multisite, esta tabela armazena os metadados dos usuários para cada site (não é uma recriação do wp_usermeta em uma instalação de site único).
Tabelas específicas do site também são adicionadas ao seu banco de dados, ou seja , wp_2_commentmeta, wp_2_comments, wp_2_links . Os dados do seu site principal são armazenados em tabelas não numeradas existentes e os sites subseqüentes possuem seus dados armazenados em tabelas numeradas seguindo a estrutura de nomeação das tabelas do site principal.
Plugins Use seu banco de dados, também
Quando você instala um plugin, ele usará seu banco de dados para armazenar e recuperar dados relacionados a esse plugin. Por exemplo, um plugin de campos personalizados salvaria os campos que ele cria no banco de dados e, em seguida, recuperá-los mais tarde para exibir em postagens associadas. Sem o banco de dados, o plugin não seria capaz de armazenar nenhum campo que ele crie, associe um campo com uma publicação ou valores de consulta para exibição no front-end.
Os plugins podem usar as tabelas de banco de dados padrão do WordPress, como wp_posts ou wp_postsmeta , ou criar tabelas personalizadas . Um exemplo popular de um plugin que cria suas próprias tabelas é o WooCommerce, que cria oito tabelas personalizadas para armazenar e recuperar IDs de produtos, itens de pedidos, taxas de imposto e outras informações sobre o produto.
Se você está preocupado com o plugin criando tabelas em seu banco de dados, não – é comum para os plugins fazer isso. Embora seja preferível usar tabelas existentes , como wp_options , para armazenar dados de plugins, nem sempre é possível, especialmente com plugins mais complexos, como o WooCommerce.
Nota: é uma boa idéia excluir tabelas personalizadas do seu banco de dados quando você remove um plugin do seu site, caso contrário, ao longo da vida útil da sua instalação, você acumulará uma coleção de tabelas não utilizadas em seu banco de dados. Alguns plugins vêm com a opção de excluir automaticamente todos os dados associados a um plugin quando você o desinstala. Tenha em mente que você deve excluir tabelas personalizadas quando tiver certeza absoluta de que não vai usar um plugin específico novamente porque não há retorno.
Motores de armazenamento MySQL explicados
O MySQL usa mecanismos de armazenamento para armazenar, manipular e recuperar informações de uma tabela. Enquanto o MySQL oferece suporte para 13 mecanismos de armazenamento diferentes, as duas opções mais usadas são MyISAM e InnoDB.
Na maioria das vezes, o mecanismo de armazenamento padrão, conforme definido em seu arquivo de configuração do MySQL, geralmente é MyISAM, e isso é o que as pessoas costumam usar. Como muitas pessoas não se importam em tomar o tempo para escolher um mecanismo de armazenamento, eles apenas usam o padrão.
Se você decidir selecionar um mecanismo de armazenamento, com o WordPress é uma decisão que facilitou um pouco – enquanto o MyISAM pode ser mais rápido para leitura, o InnoDB é mais rápido para ler e escrever graças ao mecanismo de bloqueio de linha. Como o WordPress depende muito da leitura e da escrita, a InnoDB é a melhor escolha.
Vale ressaltar que, por tabela padrão criada no phpMyAdmin, use o mecanismo de armazenamento MyISAM. Normalmente, isso significa que, se você usar hospedagem compartilhada ou um host não especializado do WordPress, suas tabelas usarão o MyISAM em vez do InnoDB. Se você quiser mudar seu mecanismo de armazenamento, você pode usar a seguinte consulta SQL (que você pode executar em sua ferramenta de gerenciamento de banco de dados favorita, como phpMyAdmin):
SET default_storage_engine=InnoDB;
Nota: Por algum motivo incrivelmente estranho, as tabelas criadas em / por phpMyAdmin usam, por padrão, MyISAM. Isso significa que se você usar hospedagem compartilhada ou um host não especialista, suas tabelas serão MyISAM. Não temas! Você pode alterar o mecanismo que está sendo usado pelo seu banco de dados. Para mudar uma tabela, você pode usar:
ALTER TABLE table_name ENGINE = InnoDB; |
Alterar a tabela do mecanismo de armazenamento por tabela pode ser um processo demorado, caso em que você pode querer dar uma olhada no excelente tutorial do Pantheon .
Agora você está pensando: “Ótimo! Mas e os plugins que criam tabelas personalizadas – qual motor eles usam? “A resposta é: eles podem usar uma mistura. Alguns declaram instruções SQL para usar o InnoDB, enquanto outros usam MyISAM. No geral, é melhor manter um olho em seu banco de dados depois de instalar um novo plugin que cria tabelas personalizadas e verificar qual mecanismo MySQL está usando.
Wp_Query
A WP_Query
classe é uma consulta extremamente poderosa do WordPress que você pode usar para acessar posts no seu banco de dados. Nós já cobrimos WP_Query
extensivamente neste blog antes, então só estou apenas apontando isso aqui.
Otimizando seu banco de dados do WordPress
Uma das razões mais comuns para um site lento é um banco de dados não otimizado, mal mantido.
Examinamos as vantagens de escolher um mecanismo de banco de dados e agora veremos como você pode remover alguns dos lixo armazenados em seu site para torná-lo mais enxuto.
Antes de começar com a otimização do seu banco de dados, é uma boa idéia criar um backup completo no caso de você ter algum problema. Eu recomendo o Snapshot Pro , nosso plugin de backup. Pode fazer backup e restaurar todo o seu site com um clique, completo com a integração Dropbox e S3.
Apenas instale plugins que você realmente está indo usar
Uma maneira simples de otimizar seu banco de dados sem realmente fazer nada é instalar plugins que você usará e não instalará plugins por motivos de instalação de plugins. É fácil atrair para ativar novos plugins brilhantes! Basta lembrar que, para cada plugin que você instala, serão criados novos dados que, por sua vez, preencherão seu banco de dados.
Existem plugins conhecidos por armazenar quantidades significativas de dados, e estes normalmente se dividem em quatro categorias:
- Plugins de segurança – A maioria dos plugins de segurança coletam e armazenam informações sobre ataques feitos contra seu site para protegê-lo de futuros ataques, spam, tentativas de login e muito mais.
- Plugins de Estatísticas – Esses plugins não extraem dados de uma fonte de terceiros, ou seja, Google Analytics, e, em vez disso, armazenam métricas como página, visitas, navegadores, palavras-chave e muito mais em seu banco de dados.
- Plugins Anti-Spam – Devido à própria natureza dos plugins anti-spam, eles armazenam enormes quantidades de dados, assim como plugins de segurança, incluindo informações como endereços IP, endereços de e-mail, países, etc.
- Plugins de publicações populares – Manter um registro de coisas como visualizações e curtimentos em centenas ou milhares de postagens, acrescenta-se e pode aumentar seu banco de dados. Melhor manter esses plugins ao mínimo.
Então, você deve parar de usar os plugins acima? Sim e não. Enquanto você deve levar o spam e a segurança do seu site muito a sério, a menos que seja necessário para o tipo de site que você executar, tente e evite os plugins estatísticos e populares.
Spam
Os comentários de spam são uma das principais causas de um banco de dados inchado se não for mantido corretamente. Eu vi sites com dezenas de milhares de comentários de spam. Por sorte, não pode ser mais simples removê-los.
Execute um comando SQL assim:
DELETE FROM wp_comments WHERE comment_approved = ‘spam'
Ou, se você fizer login no seu painel do WordPress e ir para Comentários > Spam, você deve ver um botão “Empty spam”. Clique nele e todos os comentários de spam em sua instalação desaparecerão para bem. Antes de remover todos os comentários de spam, certifique-se de que são realmente spam. É comum que os comentários sejam marcados como spam quando, de fato, são genuínos.
Se você não quiser lidar com o spam manualmente, o plugin mais popular para parar o spam em suas faixas é o Akismet, que permite que você crie comentários de spam para serem excluídos automaticamente.
Revisões
O WordPress 2.6 apresentou um recurso de revisão de postagem, que permite armazenar versões anteriores de uma publicação, ou seja, salva todos os rascunhos e atualizações. Ao contrário da crença popular, apenas uma gravação automática é mantida por postagem, removendo automaticamente a versão antiga autenticada. Isso significa que sua tabela não continuará crescendo com autosaves. No entanto, sua tabela aumentará toda vez que você clicar em “Atualizar” na sua publicação ou salvar um novo rascunho.
Embora as revisões sejam úteis e eu não as desativaria pessoalmente, nem recomendaria desativá-las, você pode economizar espaço em seu banco de dados removendo revisões antigas. Para manter um número máximo de revisões, você pode adicionar uma definição útil ao seu arquivo wp-config.php :
define( 'WP_POST_REVISIONS', 5 );
Basta alterar o número para as revisões que deseja manter. Ao inserir 1 ou mais lojas, o número de revisões mais a gravação automática, -1 armazena todas as revisões e 0 configura-a como falso e não armazena nenhuma revisão, exceto a gravação automática.
Para remover revisões de postagens existentes, você precisará executar um comando SQL para removê-los ou usar um plugin de otimização do WordPress para removê-los. Se você deseja usar o SQL, você pode executar um comando como este:
DELETE a, b, c FROM wp_posts a | |
LEFT JOIN wp_term_relationships b ON ( a . ID = b . Object_id ) | |
LEFT JOIN wp_postmeta c ON ( a . ID = c . Post_id ) | |
ONDE a . Post_type = ‘ revision ‘ |
Esta consulta exclui todas as revisões de postagem dessas postagens, mas também remove todas as meta e taxonomias associadas. Lembre-se, porém, que isso exclui todas as revisões e não apenas algumas.
Se você preferir usar um plugin para remover as revisões, verifique Otimizar banco de dados depois de excluir revisões . Não só permite que você remova as revisões, mas também a compatibilidade com vários idiomas e permite que você exclua coisas como tags não utilizadas, meta de publicação orphan e muito mais.
Eliminando tabelas não utilizadas
Os complementos que criam tabelas personalizadas com bastante frequência não os excluem na desinstalação. Se você remover um plugin e não planeja usá-lo novamente, você deseja remover a tabela que ele cria. Embora existam plugins como o WPDBSpringClean que podem fazer isso por você, ele não foi atualizado em mais de dois anos e, em geral, você não deve usar um plugin para excluir tabelas.
Não existe uma maneira fácil de saber quais tabelas de banco de dados não estão sendo usadas, embora geralmente os plugins nomeiam suas tabelas usando o nome do plugin ou a classe principal do plugin, tornando-os mais fáceis de encontrar. Claro, como já mencionei, antes de excluir tabelas ou modificar seu banco de dados, certifique-se de criar um backup completo.
Otimizando manualmente seu banco de dados
O MySQL vem com uma consulta OPTIMIZE que, de acordo com o manual oficial, “Reorganiza o armazenamento físico de dados de tabela e dados de índice associados, para reduzir o espaço de armazenamento e melhorar a eficiência de E / S ao acessar a tabela”. As mudanças exatas feitas para Cada tabela depende do mecanismo de armazenamento usado por essa tabela.
Você pode executar uma consulta OPTIMIZE usando uma ferramenta de gerenciamento de banco de dados, como phpMyAdmin.
Otimizando seu banco de dados com um complemento
Se você preferir que um plugin faça todo o trabalho para você, o WP-Optimizeé uma opção gratuita popular que está ativa em mais de 500.000 instalações do WordPress. Ele pode remover revisões de postagem, metadados antigos, rascunhos e também eliminar os comentários destruídos.
Também pode aplicar a consulta nativa OPTIMIZE sem que você tenha que usar uma ferramenta de gerenciamento de banco de dados ou uma consulta manual em sua ferramenta de gerenciamento de banco de dados. Muito fácil!
GERENCIAMENTO DE SITE
Gerencie vários sites do WordPress com o Hub
O Hub é o seu controle de missão para monitorar as estatísticas vitais de todos os seus sites, incluindo tempo de atividade, desempenho e segurança. Adicione tantos sites como deseje, incluindo redes multisite, e receba alertas de segurança instantâneos, execute varreduras de desempenho e obtenha notificações quando qualquer um dos seus plugins ou temas precisa ser atualizado.
Reparando seu banco de dados WordPress
Se o seu banco de dados ficar corrompido por qualquer motivo, não entre em pânico! Você pode editar seu arquivo wp-config.php para repará-lo:
define('WP_ALLOW_REPAIR', true);
Quando você salvou seu arquivo, acione seu navegador e vá para www.example.com/wp-admin/maint/repair.php
Na tela de reparo, você pode apenas consertar seu banco de dados ou reparar e otimizar seu banco de dados. Depois de escolher qualquer uma das opções, o WordPress tentará e reparará automaticamente seu banco de dados.
Às vezes, reparar seu banco de dados dessa maneira não funciona, ou apenas funciona parcialmente. Nessa instância, abra phpMyAdmin e tente reparar seu banco de dados tabela por tabela.
Mas e se a reparação do banco de dados dessa maneira também não funcionar? A menos que você seja um SQL ninja e especialista em recuperação de dados, este é o ponto em que você precisa recorrer a restaurar um backup anterior do seu site se você tiver um.
Como o cache de banco de dados do WordPress funciona
Eu poderia ir para sempre sobre armazenamento em cache e WordPress, pois há muito a saber, mas para este artigo abordarei as coisas mais importantes que você precisa saber.
API de Transientes
A API de Transientes é muito semelhante à API de Opções no WordPress (uma maneira simples e padronizada de armazenar dados no banco de dados que facilita a criação, acesso, atualização e exclusão de opções), mas com a característica adicional de um tempo de expiração, o que simplifica o processo de usar o wp_options tabela de banco de dados para armazenar temporariamente informações armazenadas em cache.
No WordPress, você pode usar transientes para alterar constantemente os dados que deseja expirar e atualizar, mas também como substituições para consultas de banco de dados mais intensas que você deseja armazenar em cache.
Uma desvantagem é transitorios mal codificados; Talvez o transiente tenha um tempo de expiração, mas não foi configurado para ser excluído, resultando em um transiente tentando ser carregado, o que não existe. Além disso, os proprietários de sites instalando plugins de exclusão transitória ganharam popularidade; Excluir transientes usados por plugins e temas que não devem ser excluídos podem causar vários problemas para o seu site.
Em última análise, você só deve excluir transientes se você souber exatamente o que você está fazendo e para o que eles são – não apenas eliminar em massa todos os transientes, pois há uma boa chance de você acabar com um site quebrado.
Memcached
O uso do Memcached em seu site permite acelerar consultas intensivas de banco de dados (dados e objetos) na RAM para reduzir as leituras em seu banco de dados. Isso permite que suas páginas sejam carregadas mais rapidamente, já que os dados já estão disponíveis sem ter que fazer uma consulta.
Uma desvantagem, como com todo o armazenamento em cache, é que se você atualizar sua publicação / página / site e já estiver em cache, você precisará liberar o cache antes que as alterações sejam exibidas.
Um erro que muitas pessoas costumam fazer com o Memcaching é instalar um plugin como W3 Total Cache, ver a configuração do Memcache e ativá-lo sem realmente ter a configuração do Memcached. Você não pode simplesmente configurar a opção sem configurar primeiro o banco de dados / servidor do Memcached. Um Memcached incorretamente configurado (ou qualquer cache de objetos, para esse assunto) pode destruir o seu site e banco de dados, causando entre outros problemas transientes causando problemas com atualizações automáticas e plugins / temas que dependem de transientes.
Redis
Sem dúvida, meu método favorito de armazenamento em cache com o WordPress é Redis, o que faz uma enorme diferença nos tempos de carregamento da página. Ao contrário de Memcached, Redis tem persistência embutida; Como o Memcached, a Redis também é uma loja de estrutura de dados na memória (armazenando seus dados na RAM).
Você pode usar o plugin Redis Object Cache para conectar o Redis ao seu site WordPress. Lembre-se, no entanto, que primeiro você precisará configurar o Redis e configurar seu armazenamento em cache. Uma maneira de fazer isso é com o script Predis ou a extensão Redis do HHVM (somente se usar o HHVM no lugar do PHP).
Certifique-se de configurar o Redis sensivelmente – não armazene grandes blocos de dados em cada tecla e mantenha um número razoável de chaves, pois não é útil usar o cache de banco de dados se você fizer milhares de chamadas Redis, resultando em um objeto mais longo Transações de cache.
Se você usa Memcached ou Redis, há uma diferença importante entre os dois: o Memcached é um sistema de cache de armazenamento de memória, enquanto a Redis é um servidor de estrutura de dados adequado, permitindo que ele seja usado como uma loja de dados real, em vez de apenas um cache volátil. Confira esta ótima resposta sobre o StackOverflow sobre por que você deve usar o Redis no Memcached se você ainda não tiver uma grande configuração de investimento com um sistema Memcached.
MariaDB
MariaDB é um garfo do MySQL por um dos fundadores originais e desenvolvedores do MySQL depois que foi adquirido pela Oracle.
A MariaDB é conhecida por ser significativamente mais rápida, graças à replicação mais rápida e ao conjunto de threads que permite dezenas de milhares de conexões sem uma desaceleração notável de E / S. A MariaDB também oferece um maior número de motores de armazenamento com substituições para mecanismos de armazenamento mais populares como o InnoDB.
Embora o Memcached não esteja disponível para uso com o MariaDB, você pode usar a excelente Query Cache para configurar o cache de banco de dados com o Maria DB.
Então, você deve mudar para MariaDB? É de código aberto, mais rápido e, em geral, oferece alguns recursos excelentes. Se você tem um site de tamanho médio, sim, eu definitivamente recomendaria. Mas se você estiver hospedando compartilhado barato com um pequeno site, não vale a pena o tempo ou o esforço.
Em última análise, a MariaDB é minha preferência em relação ao MySQL, especialmente devido ao seu gerenciamento de conexões, o que significa menos da mensagem temida “Não é possível estabelecer uma conexão com o banco de dados” . O que não quer dizer que o MySQL não pode ser dramaticamente melhorado através da otimização e armazenamento em cache, que vou explorar mais adiante.
WordPress e a wpdb
classe
A wpdb
classe no WordPress é o núcleo de todas as interações de banco de dados entre o software principal e seu banco de dados. Também é usado por plugins e temas.
É importante lembrar-se sempre de escapar dos seus comandos SQL para prevenir contra ataques de injeção SQL. Houve vários casos nos últimos anos, onde plugins bem conhecidos continham código SQL vulnerável, que os hackers exploraram.
Não vou também aprofundar este tópico. Em vez disso, para ler mais, confira a entrada do WordPress Codex na classe wpdb , escapando SQL no WordPress e criando tabelas personalizadas em plugins para um ótimo começo para o WordPress e a classe wpdb.
Ferramentas para ajudá-lo a gerenciar seu banco de dados
A maioria dos hosts da web oferece alguma forma de acesso ao seu banco de dados, geralmente phpMyAdmin, que fornece uma interface de usuário gráfica fácil de usar para trabalhar com seu banco de dados.
PhpMyAdmin
Um script de código aberto e aberto para gerenciamento de banco de dados. PhpMyAdmin oferece uma maneira simples de otimizar, reparar, importar, exportar e executar operações SQL no seu banco de dados. Funciona com MySQL e MariaDB.
Navicat
A Navicat é uma ferramenta premium de gerenciamento de banco de dados com alto desempenho. Além de todos os recursos padrão de qualquer boa ferramenta de gerenciamento de banco de dados, como importação / exportação, visualizador de tabela, otimização e reparo, também oferece um construtor / editor de SQL e um designer de objetos. Como o phpMyAdmin, ele funciona com MySQL e MariaDB.
Compreender como o MySQL funciona com o WordPress
Os bancos de dados são parte integrante do WordPress, fornecendo o backbone (ou arquivador) de seus sites. Assegurar que seus sites funcionem sem problemas, sejam otimizados e regularmente copiados pode ser uma tarefa demorada, mas com o conhecimento, as ferramentas e os plugins adequados, gerenciar seu banco de dados é bastante simples e simples de fazer.