Um dos arquivos mais importantes na instalação do WordPress é o arquivo wp-config.php. Esse arquivo está localizado na raiz do diretório de arquivos do WordPress e contém os detalhes de configuração básica do seu site, como informações de conexão do banco de dados.
Quando você baixa o WordPress pela primeira vez, o arquivo wp-config.php não está incluído. O processo de configuração do WordPress criará um arquivo para você com base nas informações fornecidas. wp-config.php
Você pode criar manualmente um arquivo wp-config.php localizando o arquivo de amostra denominado wp-config-sample.php(localizado no diretório de instalação raiz), editando-o conforme necessário e salvando-o como wp-config.php.
Observação: o conteúdo do arquivo wp-config-sample.php está em uma ordem muito específica. A ordem é importante. Se você já tiver um arquivo wp-config.php, reorganizar o conteúdo do arquivo pode criar erros no seu blog.
Para alterar o arquivo wp-config.php de sua instalação, você precisará destas informações:
- Nome do banco de dados – Nome do banco de dados usado pelo WordPress
- Nome de usuário do banco de dados – Nome de usuário usado para acessar o banco de dados
- Senha do banco de dados – Senha usada pelo usuário para acessar o banco de dados
- Host do banco de dados – o nome do host do seu servidor de banco de dados. Um número de porta, caminho de arquivo de soquete Unix ou canal também pode ser necessário.
Se o seu provedor de hospedagem instalou o WordPress para você, obtenha as informações com ele. Se você gerencia seu próprio servidor web ou conta de hospedagem, terá essas informações como resultado da criação do banco de dados e do usuário .
Definir configurações de banco de dados
Importante: nunca use um processador de texto como o Microsoft Word para editar arquivos WordPress!
Localize o arquivo wp-config-sample.php no diretório base do diretório do WordPress e abra em um editor de texto.
Wp-config-sample.php padrão
Nota: Este é um exemplo de wp-config-sample.php padrão. Os valores aqui são exemplos para mostrar o que fazer.
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );
/** MySQL database username */
define( 'DB_USER', 'username_here' );
/** MySQL database password */
define( 'DB_PASSWORD', 'password_here' );
/** MySQL hostname */
define( 'DB_HOST', 'localhost' );Nota: O texto dentro de / * * / são comentários , apenas para fins informativos.
Definir o nome do banco de dados
Substitua ‘database_name_here’, pelo nome do seu banco de dados, por exemplo, MyDatabaseName.
define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database nameDefinir Usuario do Banco de Dados
Substitua ‘username_here’, pelo nome do seu nome de usuário, por exemplo, MyUserName .
define( 'DB_USER', 'MyUserName' ); // Example MySQL usernameDefinir Senha do Banco de Dados
Substitua ‘password_here’ pela sua senha, por exemplo, MyPassWord.
define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL passwordDefinir banco de dados do host
Substitua ‘localhost’ pelo nome do host do seu banco de dados, por exemplo, MyDatabaseHost . Um número de porta ou caminho de arquivo de soquete Unix também pode ser necessário.
define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database hostObservação: há uma boa chance de você NÃO precisar alterá-lo. Se você não tiver certeza, tente instalar com o valor padrão ‘localhost’ e veja se funciona. Se a instalação falhar, entre em contato com seu provedor de hospedagem na web.
PORTA ALTERNATIVA DO MYSQL
Se seu host usar um número de porta alternativo para seu banco de dados, você precisará alterar o valor DB_HOST no arquivo wp-config.php para refletir a porta alternativa fornecida por seu host.
Para localhost:
Define( 'DB_HOST', '127.0.0.1:3307' );ou em alguns casos:
define( 'DB_HOST', 'localhost:3307' );Para o servidor especificado:
define( 'DB_HOST', 'mysql.example.com:3307' );Substitua 3307 pelo número de porta fornecido pelo seu host.
SOCKETS OU PIPES MYSQL
Se o seu host usa sockets ou canais Unix, ajuste o valor DB_HOST no arquivo wp-config.php de acordo.
define( 'DB_HOST', '127.0.0.1:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );
// or define( 'DB_HOST', 'example.tld:/var/run/mysqld/mysqld.sock' );Substitua /var/run/mysqld/mysqld.sockpelas informações do soquete ou tubo fornecidas por seu host.
POSSÍVEIS VALORES DB_HOST
Diferentes empresas de hospedagem usam diferentes configurações de rede para seus bancos de dados mysql. Se sua empresa de hospedagem estiver listada abaixo na coluna à esquerda, o valor à direita é semelhante ao valor correto para DB_HOST. Entre em contato com o suporte técnico e / ou pesquise a documentação online das empresas de hospedagem para ter certeza.
| Hosting Company | DB_HOST Value Guess |
|---|---|
| 1and1 | db12345678 |
| A2 Hosting | localhost |
| AN Hosting | localhost |
| Aruba.it | localhost or real IP provided with activation mail. |
| A Small Orange | localhost |
| AT&T | xxxxxxxx.carrierzone.com full server name found in PHP MyAdmin. |
| BlueHost | localhost |
| DreamHost | mysql.example.com |
| GoDaddy – Shared and 4GH Hosting | In the Databases menu go to MySQL. To the right of the database name click on Actions and Details. The hostname is at the bottom of the window. |
| GoDaddy – cPanel Hosting | localhost |
| GoDaddy – Plesk Hosting | Use the IP address shown in the Databases Section in Plesk. Do not include :3306 |
| HostGator | localhost |
| ICDSoft | localhost:/tmp/mysql5.sock |
| Infomaniak Network | mysql.yourdomain |
| InMotion Hosting | localhost |
| iPage | username.ipagemysql.com |
| IPower | username.ipowermysql.com |
| Laughing Squid | localhost |
| MediaTemple Grid | internal-db.s00000.gridserver.com – (Replace “00000” with the actual site number) |
| MediaTemple DV | localhost |
| MegaHost | localhost |
| NearlyFreeSpeech.Net | username.db |
| NetworkSolutions | mysqlv5 |
| one.com | example.com.mysql |
| pair Networks | dbnnnx.pair.com |
| QTH.com | localhost |
| Rackspace Cloud | localhost for unmanaged servers, variable for Cloud Sites like mysqlXY-AB.wcN.dfQ.stabletransit.com where X,Y,A,B,N,Q are variables |
| SysFix.eu Power Hosting | datapower.sysfix.eu |
| Site5 | localhost |
| Yahoo | mysql |
| Hosts with cPanel | localhost |
| Hosts with Plesk | localhost |
| Hosts with DirectAdmin | localhost |
| Tophost.it | sql.your-domain-name.it |
Conjunto de caracteres de banco de dados
DB_CHARSET foi disponibilizado para permitir a designação do conjunto de caracteres do banco de dados (por exemplo, tis620 para TIS620 tailandês) a ser usado ao definir as tabelas do banco de dados MySQL.
O valor padrão de utf8 ( Unicode UTF-8 ) é quase sempre a melhor opção. UTF-8 oferece suporte a qualquer idioma, portanto, você normalmente deseja deixar DB_CHARSET em utf8 e usar o valor DB_COLLATE para seu idioma.
Este exemplo mostra utf8, que é considerado o valor padrão do WordPress:
define( 'DB_CHARSET', 'utf8' );Normalmente, não deve haver razão para alterar o valor padrão de DB_CHARSET.
Database collation
DB_COLLATE foi disponibilizado para permitir a designação do agrupamento do banco de dados (ou seja, a ordem de classificação do conjunto de caracteres). Na maioria dos casos, esse valor deve ser deixado em branco (nulo) para que o agrupamento do banco de dados seja atribuído automaticamente pelo MySQL com base no conjunto de caracteres do banco de dados especificado por DB_CHARSET. Um exemplo de quando você pode precisar definir ”’DB_COLLATE”’ para um dos valores UTF-8 definidos em conjuntos de caracteres UTF-8 para a maioria dos idiomas da Europa Ocidental seria quando um idioma diferente em que os caracteres que você inseriu não são os igual ao que está sendo exibido. (Consulte também Conjuntos de caracteres Unicode no manual SQL)
O valor DB_COLLATE padrão do WordPress:
define( 'DB_COLLATE', '' );Agrupamento geral UTF-8 Unicode
define( 'DB_COLLATE', 'utf8_general_ci' );Agrupamento turco UTF-8 Unicode
define( 'DB_COLLATE', 'utf8_turkish_ci' );Normalmente não deve haver razão para alterar o valor padrão de DB_COLLATE. Deixar o valor em branco (nulo) garantirá que o agrupamento seja atribuído automaticamente pelo MySQL quando as tabelas do banco de dados forem criadas.
AVISO: Aqueles que realizam atualizações
Se DB_COLLATE e DB_CHARSET não existirem em seu arquivo wp-config.php, NÃO adicione nenhuma definição ao seu arquivo wp-config.php, a menos que você leia e compreenda a conversão de conjuntos de caracteres de banco de dados . E você pode precisar de uma atualização do WordPress.
Chaves de segurança (Security Keys)
Você não precisa se lembrar das chaves, apenas torná-las longas, aleatórias e complicadas – ou melhor ainda, use o gerador online . Você pode alterá-los a qualquer momento para invalidar todos os cookies existentes. Isso significa que todos os usuários terão que fazer o login novamente.
Exemplo (não use estes!):
define( 'AUTH_KEY', 't`DK%X:>xy|e-Z(BXb/f(Ur`8#~UzUQG-^_Cs_GHs5U-&Wb?pgn^p8(2@}IcnCa|' );
define( 'SECURE_AUTH_KEY', 'D&ovlU#|CvJ##uNq}bel+^MFtT&.b9{UvR]g%ixsXhGlRJ7q!h}XWdEC[BOKXssj' );
define( 'LOGGED_IN_KEY', 'MGKi8Br(&{H*~&0s;{k0<S(O:+f#WM+q|npJ-+P;RDKT:~jrmgj#/-,[hOBk!ry^' );
define( 'NONCE_KEY', 'FIsAsXJKL5ZlQo)iD-pt??eUbdc{_Cn<4!d~yqz))&B D?AwK%)+)F2aNwI|siOe' );
define( 'AUTH_SALT', '7T-!^i!0,w)L#JK@pc2{8XE[DenYI^BVf{L:jvF,hf}zBf883td6D;Vcy8,S)-&G' );
define( 'SECURE_AUTH_SALT', 'I6`V|mDZq21-J|ihb u^q0F }F_NUcy`l,=obGtq*p#Ybe4a31R,r=|n#=]@]c #' );
define( 'LOGGED_IN_SALT', 'w<$4c$Hmd%/*]`Oom>(hdXW|0M=X={we6;Mpvtg+V.o<$|#_}qG(GaVDEsn,~*4i' );
define( 'NONCE_SALT', 'a|#h{c5|P &xWs4IZ20c2&%4!c(/uG}W:mAvy<I44`jAbup]t=]V<`}.py(wTP%%' );Uma chave secreta torna o seu site mais difícil de atacar com sucesso, adicionando elementos aleatórios à senha.
Em termos simples, uma chave secreta é uma senha com elementos que tornam mais difícil gerar opções suficientes para quebrar suas barreiras de segurança. Uma senha como “senha” ou “teste” é simples e facilmente quebrada. Uma senha longa e aleatória que não usa palavras do dicionário, como “88a7da62429ba6ad3cb3c76a09641fc” levaria milhões de horas para um atacante de força bruta decifrá-la. Um sal é usado para aumentar ainda mais a segurança do resultado gerado.
As quatro chaves são necessárias para a segurança aprimorada. Os quatro sais são recomendados, mas não são obrigatórios, porque o WordPress gerará sais para você se nenhum for fornecido. Eles são incluídos wp-config.phppor padrão para inclusão.
Para obter mais informações sobre o histórico técnico e detalhamento de chaves secretas e senhas seguras, consulte:
- Ryan Boren – SSL e Cookies no WordPress 2.6
- Explicação da Wikipedia sobre quebra de senha
- Lorelle VanFossen – Proteja seu blog com uma senha sólida
- Instructables – Dicas de senha de segurança
- Huffington Post – 17 dicas que você pode fazer hoje para proteger suas senhas online
Opções avançadas
As seções a seguir podem conter informações avançadas e algumas alterações podem resultar em problemas imprevistos. Certifique-se de praticar backups regulares e saber como restaurá-los antes de modificar essas configurações.
table_prefix
O $table_prefix é o valor colocado na frente de suas tabelas de banco de dados. Altere o valor se quiser usar algo diferente de wp_ para o prefixo do banco de dados. Normalmente, isso é alterado se você estiver instalando vários blogs do WordPress no mesmo banco de dados, como é feito com o recurso multisite.
É possível ter várias instalações em um banco de dados se você der a cada um um prefixo exclusivo. Lembre-se de segurança se decidir fazer isso.
$table_prefix = 'r235_'; // Only numbers, letters, and underscores please!WP_SITEURL
WP_SITEURL permite que o endereço do WordPress (URL) seja definido. O valor definido é o endereço onde residem seus arquivos principais do WordPress. Deve incluir a http://parte também. Não coloque uma barra “ / ” no final. Definir esse valor em wp-config.phpsubstitui o valor da tabela wp_options para siteurl . Adicionar isso pode reduzir o número de chamadas de banco de dados ao carregar seu site. Nota: Isso não mudará o valor armazenado no banco de dados. O URL será revertido para o valor do banco de dados antigo se esta linha for removida wp-config. Use a constante RELOCATE para alterar o valor do siteurl no banco de dados.
Se o WordPress estiver instalado em um diretório chamado “wordpress” para o domínio example.com, defina WP_SITEURL assim:
define( 'WP_SITEURL', 'http://example.com/wordpress' );Defina WP_SITEURL dinamicamente com base em $ _SERVER [‘HTTP_HOST’]
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );Nota: HTTP_HOST é criado dinamicamente pelo PHP com base no valor do cabeçalho HTTP HOST na solicitação, possivelmente permitindo vulnerabilidades de inclusão de arquivo . SERVER_NAME também pode ser criado dinamicamente. No entanto, quando o Apache é configurado como UseCanonicalName “on”, SERVER_NAME é definido pela configuração do servidor, em vez de dinamicamente. Nesse caso, é mais seguro para o usuário SERVER_NAME do que HTTP_HOST.
Defina WP_SITEURL dinamicamente com base em $ _SERVER [‘SERVER_NAME’]
define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpress' );Endereço do blog (URL)
Semelhante a WP_SITEURL, WP_HOME substitui o valor da tabela wp_options para home, mas não o altera no banco de dados. home é o endereço que você deseja que as pessoas digitem em seus navegadores para acessar seu blog do WordPress. Deve incluir a http://parte e não deve ter uma barra “ / ” no final. Adicionar isso pode reduzir o número de chamadas de banco de dados ao carregar seu site.
define (‘WP_HOME’, ‘http://example.com/wordpress’);
Se você estiver usando a técnica descrita em Fornecendo ao WordPress seu próprio diretório , siga o exemplo abaixo. Lembre-se de que você também colocará um index.phpno diretório raiz da web se usar uma configuração como esta.
define( 'WP_HOME', 'http://example.com' );Defina WP_HOME dinamicamente com base em $ _SERVER [‘HTTP_HOST’]
define( 'WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress' );Movendo a pasta wp-content
Você pode mover o wp-contentdiretório, que contém seus temas, plug-ins e uploads, para fora do diretório do aplicativo WordPress.
Defina WP_CONTENT_DIR para o caminho local completo deste diretório (sem barra final), por exemplo:
define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/blog/wp-content' );Defina WP_CONTENT_URL para a URL completa deste diretório (sem barra final), por exemplo
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content' );Movendo a pasta do plugin
Defina WP_PLUGIN_DIR para o caminho local completo deste diretório (sem barra final), por exemplo:
define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/blog/wp-content/plugins' );Defina WP_PLUGIN_URL para o URI completo deste diretório (sem barra final), por exemplo
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins' );Se você tiver problemas de compatibilidade com plug-ins Defina PLUGINDIR para o caminho local completo deste diretório (sem barra), por exemplo
define( 'PLUGINDIR', dirname(__FILE__) . '/blog/wp-content/plugins' );Movendo pasta de temas
Você não pode mover a pasta de temas porque seu caminho está codificado em relação à wp-contentpasta:
$ theme_root = WP_CONTENT_DIR. '/temas';
No entanto, você pode registrar diretórios de tema adicionais usando register_theme_directory .
Veja como mover a pasta wp-content . Para obter mais detalhes sobre como a pasta de temas é determinada, consulte wp-includes/theme.php.
Movendo pasta de uploads
Defina UPLOADS para:
define ('UPLOADS', 'blog / wp-content / uploads');
Este caminho não pode ser absoluto. É sempre relativo a ABSPATH, portanto, não requer uma barra inicial.
Modificar intervalo de salvamento automático
Ao editar uma postagem, o WordPress usa Ajax para salvar automaticamente as revisões da postagem à medida que você edita. Você pode querer aumentar esta configuração para atrasos mais longos entre os salvamentos automáticos ou diminuir a configuração para ter certeza de nunca perder as alterações. O padrão é 60 segundos.
define ('AUTOSAVE_INTERVAL', 160); // segundos
Postar revisões
O WordPress, por padrão, salvará cópias de cada edição feita em um post ou página, permitindo a possibilidade de reverter para uma versão anterior desse post ou página. O salvamento de revisões pode ser desativado ou um número máximo de revisões por postagem ou página pode ser especificado.
Desativar revisões de postagem
Se você não definir esse valor, o padrão do WordPress WP_POST_REVISIONS será verdadeiro (habilitar revisões posteriores). Se você deseja desativar o recurso de revisões incríveis, use esta configuração:
define ('WP_POST_REVISIONS', false);
Nota: Alguns usuários não conseguiram fazer isso funcionar até mover o comando para a primeira linha sob o comentário do bloco inicial em wp-config.php.
Especifique o número de revisões de postagens
Se você deseja especificar um número máximo de revisões que o WordPress armazena, altere false para um inteiro / número ( por exemplo , 3 ou 12).
define ('WP_POST_REVISIONS', 3);
Nota: Alguns usuários não conseguiram fazer isso funcionar até mover o comando para a primeira linha sob o comentário do bloco inicial em wp-config.php.
Definir cookie de domínio
O domínio definido nos cookies para WordPress pode ser especificado para aqueles com configurações de domínio incomuns. Por exemplo, se subdomínios são usados para servir conteúdo estático, você pode definir o domínio do cookie para apenas seu domínio não estático para evitar que cookies do WordPress sejam enviados com cada solicitação de conteúdo estático em seu subdomínio.
define ('COOKIE_DOMAIN', 'www.example.com');
Habilitar capacidade multisite / rede
WP_ALLOW_MULTISITE é um recurso que habilita a funcionalidade multisite. Se esta configuração estiver ausente wp-config.php, o padrão é falso.
define ('WP_ALLOW_MULTISITE', true);
Redirecionar blogs inexistentes
NOBLOGREDIRECT pode ser usado para redirecionar o navegador se o visitante tentar acessar um subdomínio ou subpasta inexistente.
define ('NOBLOGREDIRECT', 'http://example.com');
WP_DISABLE_FATAL_ERROR_HANDLER
O WordPress 5.2 introduziu o modo de recuperação, que exibe mensagem de erro em vez de tela branca quando os plug-ins causam um erro fatal.
O site está passando por dificuldades técnicas. Verifique a caixa de entrada de e-mail do administrador do site para obter instruções.
Telas brancas e mensagens de erro de PHP não são mais exibidas para os usuários. Mas em um ambiente de desenvolvimento, se você deseja habilitar WP_DEBUG_DISPLAY, você deve desabilitar o modo de recuperação definindo true para WP_DISABLE_FATAL_ERROR_HANDLER.
define ('WP_DISABLE_FATAL_ERROR_HANDLER', true); // 5.2 e posterior define ('WP_DEBUG', true);
define ('WP_DEBUG_DISPLAY', true);
WP_DEBUG
A opção WP_DEBUG controla o relatório de alguns erros e avisos e permite o uso das configurações WP_DEBUG_DISPLAY e WP_DEBUG_LOG. O valor booleano padrão é falso.
define ('WP_DISABLE_FATAL_ERROR_HANDLER', true); // 5.2 e posterior
define ('WP_DEBUG', true);
Os erros do banco de dados são impressos apenas se WP_DEBUG for definido como verdadeiro. Os erros do banco de dados são tratados pela classe wpdb e não são afetados pelas configurações de erro do PHP .
Definir WP_DEBUG como true também aumenta o nível de relatório de erros para E_ALL e ativa avisos quando funções ou arquivos obsoletos são usados; caso contrário, o WordPress define o nível de relatório de erro para E_ALL ^ E_NOTICE ^ E_USER_NOTICE.
WP_ENVIRONMENT_TYPE
A opção WP_ENVIRONMENT_TYPE controla o tipo de ambiente para um site: local, development, staging, e production.
Os valores dos tipos de ambiente são processados na seguinte ordem com cada método sequencial substituindo quaisquer valores anteriores: a variável de ambiente WP_ENVIRONMENT_TYPE PHP e a constante WP_ENVIRONMENT_TYPE.
Para ambos os métodos, se o valor de um tipo de ambiente fornecido não estiver na lista de tipos de ambiente permitidos, o productionvalor padrão será retornado.
A maneira mais simples de definir o valor é provavelmente definindo a constante:
define( 'WP_ENVIRONMENT_TYPE', 'staging' );Obs: Quando developmentfor retornado por wp_get_environment_type () , WP_DEBUG será setado truese não estiver definido no arquivo wp-config.php do site.
SCRIPT_DEBUG
SCRIPT_DEBUG é uma constante relacionada que forçará WordPress para usar as versões “dev” de scripts e folhas de estilo em wp-includes/js, wp-includes/css, wp-admin/js, e wp-admin/cssserá carregado em vez dos .min.csse .min.jsversões .. Se você está pensando em modificar alguns dos WordPress’ built-in JavaScript ou Cascading Style Sheets, você deve adicionar o seguinte código ao seu arquivo de configuração:
define ('SCRIPT_DEBUG', true);
Desativar Concatenação Javascript
Para resultar em telas de administração mais rápidas, todos os arquivos JavaScript são concatenados em um URL. Se o JavaScript não funcionar em uma tela de administração, você pode tentar desabilitar este recurso:
define ('CONCATENATE_SCRIPTS', false);
Configurar registro de erros
Configurar o log de erros pode ser um pouco complicado. Em primeiro lugar, o log de erros padrão do PHP e as configurações de exibição são definidas no arquivo php.ini, ao qual você pode ou não ter acesso. Se você fizer isso, eles devem ser definidos com as configurações desejadas para páginas PHP ativas servidas ao público. É altamente recomendável que nenhuma mensagem de erro seja exibida ao público e, em vez disso, encaminhada para um log de erro. Além disso, os logs de erro não devem ser localizados na parte acessível publicamente do seu servidor. Exemplo de configurações de erro recomendadas de php.ini:
error_reporting = 4339 display_errors = Off display_startup_errors = Off log_errors = On error_log = /home/example.com/logs/php_error.log log_errors_max_len = 1024 ignore_repeated_errors = On ignore_repeated_source = Off html_errors = Off
Sobre o Error Reporting 4339 Este é um valor personalizado que registra apenas problemas que afetam o funcionamento do seu site e ignora coisas como avisos que podem nem mesmo ser erros. Veja PHP Error Constants para o significado de cada posição binária para 1000011110011, que é o número binário igual a 4339. O 1 mais à esquerda significa relatar qualquer E_RECOVERABLE_ERROR. O próximo 0 significa não relatar E_STRICT, (que é lançado quando uma codificação desleixada, mas funcional é usada) e assim por diante. Sinta-se à vontade para determinar seu próprio número de relatório de erro personalizado para usar no lugar de 4339.
Obviamente, você desejará configurações diferentes para seu ambiente de desenvolvimento. Se sua cópia de teste estiver no mesmo servidor ou se você não tiver acesso ao php.ini, será necessário substituir as configurações padrão em tempo de execução. É uma questão de preferência pessoal se você prefere que os erros vão para um arquivo de log ou se prefere ser notificado imediatamente sobre qualquer erro, ou talvez ambos. Aqui está um exemplo que relata todos os erros imediatamente que você pode inserir em seu arquivo wp-config.php:
@ini_set( 'log_errors', 'Off' ); @ini_set( 'display_errors', 'On' ); define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 e posterior define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', true );
Como wp-config.phpé carregado para cada visualização de página não carregada de um arquivo de cache, é um excelente local para definir as php.iniconfigurações que controlam a instalação do PHP. Isso é útil se você não tiver acesso a um php.iniarquivo ou se apenas quiser alterar algumas configurações imediatamente. Uma exceção é ‘error_reporting’. Quando WP_DEBUG é definido como verdadeiro, ‘error_reporting’ será definido como E_ALL pelo WordPress independentemente de qualquer coisa que você tente definir em wp-config.php. Se você realmente precisa definir ‘error_reporting’ para outra coisa, isso deve ser feito depois de wp-settings.phpser carregado, como em um arquivo de plugin.
Se você ativar o registro de erros, lembre-se de excluir o arquivo depois, pois geralmente estará em um local acessível publicamente, onde qualquer pessoa pode obter acesso ao seu registro.
Aqui está um exemplo que ativa o error_logging do PHP e os registra em um arquivo específico. Se WP_DEBUG for definido como verdadeiro, os erros também serão salvos neste arquivo. Basta colocá-lo acima de qualquer require_once ou incluir comandos.
@ini_set ('log_errors', 'On');
@ini_set ('display_errors', 'Off');
@ini_set ('error_log', '/home/example.com/logs/php_error.log');
/ * Isso é tudo, pare de editar! Feliz blogging. * /
/ ** * Isso registrará todos os avisos de erros e avisos em um arquivo chamado debug.log em * wp-content (se o Apache não tiver permissão de gravação, você pode precisar criar * o arquivo primeiro e definir as permissões apropriadas (ou seja, usar 666)) * / define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
/ **
* Isso registrará todos os avisos de erros e avisos em um arquivo chamado debug.log em
* wp-content apenas quando WP_DEBUG for verdadeiro. se o Apache não tiver permissão de gravação,
* você pode precisar criar o arquivo primeiro e definir as permissões apropriadas (ou seja, use 666).
* /
define( 'WP_DEBUG', true ); // ou false
if ( WP_DEBUG ) {
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
}
O problema confuso é que o WordPress tem três (3) constantes que parecem poder fazer a mesma coisa. Primeiro, lembre-se de que se WP_DEBUG for falso, ele e as outras duas constantes DEBUG do WordPress não farão nada. As diretivas PHP, quaisquer que sejam, prevalecerão. Exceto para ‘error_reporting’, o WordPress definirá isso como 4983 se WP_DEBUG for definido como falso. Em segundo lugar, mesmo se WP_DEBUG for true, as outras constantes só fazem algo se também forem definidas como true. Se forem definidas como falsas, as diretivas do PHP permanecem inalteradas. Por exemplo, se o seu php.iniarquivo tiver a diretiva (‘display_errors’ = ‘On’); mas você tem a declaração define (‘WP_DEBUG_DISPLAY’, false); na tuawp-config.php, os erros ainda serão exibidos na tela, mesmo que você tenha tentado evitá-los definindo WP_DEBUG_DISPLAY como false porque esse é o comportamento configurado do PHP. É por isso que é muito importante definir as diretivas do PHP para o que você precisa no caso de qualquer uma das constantes WP relacionadas ser definida como falsa. Para ser seguro, defina / defina explicitamente os dois tipos.
Para sua instalação pública de produção do WordPress, você pode considerar incluir o seguinte em seu arquivo wp-config.php, mesmo que seja parcialmente redundante:
@ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false ); // 5.2 and later define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', false );
O arquivo de log de depuração padrão é /wp-content/debug.log. Colocar logs de erros em locais acessíveis publicamente é um risco de segurança. Idealmente, seus arquivos de log devem ser colocados acima do diretório raiz público do site. Se você não puder fazer isso, no mínimo, defina as permissões do arquivo de log para 600 e adicione esta entrada ao .htaccessarquivo no diretório raiz de sua instalação do WordPress:
<Files debug.log>
Order allow,deny
Deny from all
</Files>
Isso impede que qualquer pessoa acesse o arquivo via HTTP. Você sempre pode visualizar o arquivo de log recuperando-o de seu servidor via FTP.
Aumentando a memória alocada para PHP
A opção WP_MEMORY_LIMIT permite que você especifique a quantidade máxima de memória que pode ser consumida pelo PHP. Esta configuração pode ser necessária caso você receba uma mensagem como “Tamanho de memória permitido de xxxxxx bytes esgotados”.
Essa configuração aumenta a memória PHP apenas para WordPress, não para outros aplicativos. Por padrão, o WordPress tentará aumentar a memória alocada para PHP para 40 /wp-includes/default-constants.phpMB (o código está no início de ) para um único site e 64 MB para vários sites, portanto, a configuração em wp-config.phpdeve refletir algo maior que 40 MB ou 64 MB, dependendo da configuração.
O WordPress verificará automaticamente se o PHP alocou menos memória do que o valor inserido antes de utilizar esta função. Por exemplo, se o PHP recebeu 64 MB, não há necessidade de definir esse valor para 64 MB, pois o WordPress usará automaticamente todos os 64 MB, se necessário.
Nota: Alguns hosts não permitem o aumento automático do limite de memória do PHP. Nesse caso, entre em contato com seu host para aumentar o limite de memória do PHP. Além disso, muitos hosts definem o limite do PHP em 8 MB.
Aumente a memória PHP para 64 MB
define ('WP_MEMORY_LIMIT', '64M');
Aumente a memória PHP para 96 MB
define ('WP_MEMORY_LIMIT', '96M');
As tarefas de administração requerem mais memória do que a operação normal. Quando na área de administração, a memória pode ser aumentada ou diminuída do WP_MEMORY_LIMIT definindo WP_MAX_MEMORY_LIMIT.
define ('WP_MAX_MEMORY_LIMIT', '256M');
Nota: isso deve ser colocado antes da inclusão wp-settings.php.
Cache
A configuração WP_CACHE , se verdadeira, inclui o wp-content/advanced-cache.phpscript, durante a execução wp-settings.php.
define( 'WP_CACHE', true );
Usuário personalizado e tabelas Usermeta
CUSTOM_USER_TABLE e CUSTOM_USER_META_TABLE são usados para designar que as tabelas user e usermeta normalmente utilizadas pelo WordPress não são usadas, em vez disso, esses valores / tabelas são usados para armazenar suas informações de usuário.
define ('CUSTOM_USER_TABLE', $ table_prefix.'my_users ');
define ('CUSTOM_USER_META_TABLE', $ table_prefix.'my_usermeta ');
Nota: Mesmo se ‘CUSTOM_USER_META_TABLE’ for definido manualmente, uma tabela usermeta ainda é criada para cada banco de dados com as permissões correspondentes para cada instância. Por padrão, o instalador do WordPress adicionará permissões para o primeiro usuário (ID # 1). Você também precisa gerenciar as permissões para cada site por meio de um plug-in ou função personalizada. Se isso não for configurado, você terá erros de permissão e problemas de login.
CUSTOM_USER_TABLE é mais fácil de adotar durante a configuração inicial sua primeira instância do WordPress. As instruções define do wp-config.phpna primeira instância apontam para onde os wp_usersdados serão armazenados por padrão. Após a configuração do primeiro site, copiar o trabalho wp-config.phppara sua próxima instância exigirá apenas uma mudança na $table_prefixvariável. Não use um endereço de e-mail que já esteja em uso pela instalação original. Depois de concluir o processo de configuração, faça login com a conta e senha de administrador geradas automaticamente. Em seguida, promova sua conta normal para o nível de administrador e saia do administrador. Faça login novamente como você mesmo, exclua a conta de administrador e promova as outras contas de usuário conforme necessário.
Idioma e diretório de idioma
O WordPress versão 4.0 permite que você altere o idioma em suas telas de administração do WordPress. Para alterar o idioma na tela de configurações do administrador. Vá para Configurações > Geral e selecione Idioma do site.
WordPress v3.9.6 e anterior
WPLANG define o nome do arquivo de tradução de idioma (.mo). WP_LANG_DIR define em qual diretório reside o arquivo WPLANG .mo. Se WP_LANG_DIR não for definido, o WordPress procurará primeiro wp-content / languages e depois wp-includes/languageso .mo definido pelo arquivo WPLANG.
define( 'WPLANG', 'de_DE' ); define( 'WP_LANG_DIR', dirname(FILE) . 'wordpress/languages' );
Para descobrir o código do idioma WPLANG, consulte aqui. O código na coluna WP Local é o que você precisa.
Salvar consultas para análise
A definição SAVEQUERIES salva as consultas do banco de dados em uma matriz e essa matriz pode ser exibida para ajudar a analisar essas consultas. As informações salvam cada consulta, qual função a chamou e quanto tempo a consulta levou para ser executada. Observação: isso terá um impacto no desempenho do seu site, portanto, certifique-se de desligar quando não estiver depurando.
Primeiro, adicione ao arquivo wp-config.php:
define ('SAVEQUERIES', true);
Então, no rodapé do seu tema, coloque o seguinte:
<? php
if (current_user_can ('administrador')) {
global $ wpdb;
echo "<pre>";
print_r ($ wpdb-> queries);
echo "</pre>";
}
?>
Substituição de permissões de arquivo padrão
As instruções FS_CHMOD_DIR e FS_CHMOD_FILE define permitem a substituição de permissões de arquivo padrão. Essas duas variáveis foram desenvolvidas em resposta ao problema da falha da função de atualização do núcleo com hosts em execução sob suexec . Se um host usa permissões de arquivo restritivas (por exemplo, 400) para todos os arquivos do usuário e se recusa a acessar arquivos que têm permissões de grupo ou mundiais definidas, essas definições podem resolver o problema.
define ('FS_CHMOD_DIR', (0755 & ~ umask ()));
define ('FS_CHMOD_FILE', (0644 & ~ umask ()));
Exemplo para fornecer setgid:
define ('FS_CHMOD_DIR', (02755 & ~ umask ()));
Nota: ‘ 0755 ′ e’ 02755 ‘são valores octais. Os valores octais devem ser prefixados com 0 e não são delineados com aspas simples (‘). Consulte também: Alterando permissões de arquivo
Constantes de atualização do WordPress
Nota: Defina algumas das constantes abaixo conforme necessário para corrigir seus problemas de atualização.
As causas mais comuns de necessidade de defini-los são:
Host executando com uma configuração de instalação especial envolvendo links simbólicos. Você pode precisar definir as constantes relacionadas ao caminho (FTP_BASE, FTP_CONTENT_DIR e FTP_PLUGIN_DIR). Muitas vezes, definir simplesmente a base será o suficiente.
Certas instalações PHP vêm com uma extensão PHP FTP que é incompatível com certos servidores FTP. Nessas situações raras, você pode precisar definir FS_METHOD como “ftpsockets”.
As seguintes são constantes válidas para atualizações do WordPress:
- FS_METHOD força o método do sistema de arquivos. Deve ser apenas “direto”, “ssh2”, “ftpext” ou “ftpsockets”. Geralmente, você só deve alterar isso se estiver tendo problemas de atualização. Se você alterá-lo e não ajudar, altere-o de volta / remova-o . Na maioria das circunstâncias, defini-lo como ‘ftpsockets’ funcionará se o método escolhido automaticamente não funcionar.
- (Preferência primária) “direct” força-o a usar solicitações de I / O de arquivo direto de dentro do PHP, isso é preocupante com a abertura de problemas de segurança em hosts mal configurados. Isso é escolhido automaticamente quando apropriado.
- (Preferência secundária) “ssh2” é para forçar o uso da extensão SSH PHP se instalada
- (3ª preferência) “ftpext” é para forçar o uso da extensão FTP PHP para acesso FTP, e finalmente
- (4ª preferência) “ftpsockets” utiliza a classe PHP Sockets para acesso FTP.
- FTP_BASE é o caminho completo para a pasta “base” (ABSPATH) da instalação do WordPress.
- FTP_CONTENT_DIR é o caminho completo para a pasta wp-content da instalação do WordPress.
- FTP_PLUGIN_DIR é o caminho completo para a pasta de plug-ins da instalação do WordPress.
- FTP_PUBKEY é o caminho completo para sua chave pública SSH.
- FTP_PRIKEY é o caminho completo para sua chave privada SSH.
- FTP_USER é o nome de usuário FTP ou SSH do usuário. Provavelmente são iguais, mas use o apropriado para o tipo de atualização que deseja fazer.
- FTP_PASS é a senha para o nome de usuário inserido para FTP_USER . Se você estiver usando a autenticação de chave pública SSH, isso pode ser omitido.
- FTP_HOST é a combinação de nome de host: porta para seu servidor SSH / FTP. A porta FTP padrão é 21 e a porta SSH padrão é 22. Isso não precisa ser mencionado.
- FTP_SSL TRUE para conexão SSL se suportado pelo transporte subjacente (não disponível em todos os servidores). Isso é para “FTP seguro”, não para SSH SFTP.
define( 'FS_METHOD', 'ftpext' ); define( 'FTP_BASE', '/path/to/wordpress/' ); define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' ); define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' ); define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' ); define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' ); define( 'FTP_USER', 'username' ); define( 'FTP_PASS', 'password' ); define( 'FTP_HOST', 'ftp.example.org' ); define( 'FTP_SSL', false );
Algumas configurações devem definir FTP_HOST para localhost para evitar 503 problemas ao tentar atualizar plug-ins ou o próprio WP.
Habilitando acesso de atualização SSH
Existem duas maneiras de atualizar usando SSH2.
A primeira é usar o plugin SSH SFTP Updater Support . A segunda é usar o atualizador SSH2 integrado, que requer que a extensão pecl SSH2 seja instalada.
Para instalar a extensão pecl SSH2, você precisará emitir um comando semelhante ao seguinte ou falar com seu provedor de hospedagem na web para instalá-lo:
pecl install ssh2
Depois de instalar a extensão pecl ssh2, você precisará modificar a configuração do PHP para carregar automaticamente esta extensão.
pecl é fornecido pelo pacote pear na maioria das distribuições Linux. Para instalar pecl no Redhat / Fedora / CentOS:
yum -y install php-pear
Para instalar pecl no Debian / Ubuntu:
apt-get install php-pear
É recomendável usar uma chave privada que não seja protegida por senha. Há vários relatos de que as chaves privadas protegidas por senha não funcionam corretamente. Se você decidir tentar uma chave privada protegida por frase secreta, precisará inserir a frase secreta para a chave privada como FTP_PASS ou digitá-la no campo “Senha” no campo de credencial apresentado ao instalar atualizações.
Cron alternativo
Pode haver razão para usar um Cron alternativo com WP. Mais comumente, isso é feito se as postagens programadas não estão sendo publicadas conforme previsto. Este método alternativo usa uma abordagem de redirecionamento. O navegador dos usuários obtém um redirecionamento quando o cron precisa ser executado, para que eles voltem ao site imediatamente, enquanto o cron continua a ser executado na conexão que acabaram de desligar. Este método apresenta alguns riscos, pois depende de um serviço WordPress não nativo.
define( 'ALTERNATE_WP_CRON', true );
Desativar Cron e Tempo Limite de Cron
Desative o cron completamente definindo DISABLE_WP_CRON como verdadeiro.
define( 'DISABLE_WP_CRON', true );
Certifique-se de que um processo cron não possa ser executado mais de uma vez a cada WP_CRON_LOCK_TIMEOUT segundos.
define( 'WP_CRON_LOCK_TIMEOUT', 60 );
Constantes Definidas Adicionais
Aqui estão constantes adicionais que podem ser definidas. Isso provavelmente não deve ser definido, a menos que outras metodologias tenham sido tentadas primeiro. As definições de cookie podem ser particularmente úteis se você tiver uma configuração de domínio incomum.
define( 'COOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'home' ) . '/' ) ); define( 'SITECOOKIEPATH', preg_replace( '|https?://[^/]+|i', '', get_option( 'siteurl' ) . '/' ) ); define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' ); define( 'PLUGINS_COOKIE_PATH', preg_replace( '|https?://[^/]+|i', '', WP_PLUGIN_URL ) ); define( 'TEMPLATEPATH', get_template_directory() ); define( 'STYLESHEETPATH', get_stylesheet_directory() );
Esvaziar lixeira
Essa constante controla o número de dias antes que o WordPress exclua permanentemente postagens, páginas, anexos e comentários da lixeira. O padrão é 30 dias:
define( 'EMPTY_TRASH_DAYS', 30 ); // 30 days
Para desativar a lixeira, defina o número de dias como zero.
define( 'EMPTY_TRASH_DAYS', 0 ); // Zero days
Observação: o WordPress não pedirá confirmação quando alguém clicar em “Excluir permanentemente” usando esta configuração.
Otimização automática de banco de dados
Há suporte para reparo automático de banco de dados, que você pode ativar adicionando o seguinte definir ao seu arquivo wp-config.php.
Nota: Isso só deve ser habilitado se necessário e desabilitado assim que o problema for resolvido. Quando ativado, o usuário não precisa estar logado para acessar a funcionalidade, uma vez que sua principal intenção é reparar um banco de dados corrompido e os usuários muitas vezes não conseguem fazer o login quando o banco de dados está corrompido.
define( 'WP_ALLOW_REPAIR', true );
O script pode ser encontrado em {$your_site}/wp-admin/maint/repair.php.
DO_NOT_UPGRADE_GLOBAL_TABLES
Uma definição DO_NOT_UPGRADE_GLOBAL_TABLES impede que dbDelta () e as funções de atualização façam consultas caras em tabelas globais.
Sites que têm grandes tabelas globais (particularmente usuários e usermeta), bem como sites que compartilham tabelas de usuários com o bbPress e outras instalações do WordPress, podem impedir que a atualização altere essas tabelas durante a atualização, definindo DO_NOT_UPGRADE_GLOBAL_TABLES como verdadeiro. Como um ALTER, ou um DELETE ou UPDATE ilimitado, pode levar muito tempo para ser concluído, sites grandes geralmente desejam evitar que sejam executados como parte da atualização para que possam lidar com isso sozinhos. Além disso, se as instalações estiverem compartilhando tabelas de usuário entre várias instalações do bbPress e do WordPress, você pode querer que um site seja o mestre da atualização.
define( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true );
Ver todas as constantes definidas
O PHP tem uma função que retorna um array de todas as constantes definidas atualmente com seus valores.
print_r( @get_defined_constants() );
Desative o Plugin e Editor de Tema
Ocasionalmente, você pode desejar desativar o plugin ou editor de tema para evitar que usuários excessivamente zelosos possam editar arquivos confidenciais e potencialmente travar o site. Desativá-los também fornece uma camada adicional de segurança se um hacker obtiver acesso a uma conta de usuário com bons privilégios.
define( 'DISALLOW_FILE_EDIT', true );
Nota : A funcionalidade de alguns plug-ins pode ser afetada pelo uso de current_user_can('edit_plugins')em seu código. Os autores do plug-in devem evitar verificar esse recurso ou, pelo menos, verificar se essa constante está definida e exibir uma mensagem de erro apropriada. Esteja ciente de que, se um plugin não estiver funcionando, essa pode ser a causa.
Desative a atualização e instalação de plug-ins e temas
Isso impedirá que os usuários usem a funcionalidade de instalação / atualização do plugin e do tema na área de administração do WordPress. Definir esta constante também desativa o editor de plug-ins e temas (ou seja, você não precisa definir DISALLOW_FILE_MODS e DISALLOW_FILE_EDIT, pois em seu próprio DISALLOW_FILE_MODS terá o mesmo efeito).
define( 'DISALLOW_FILE_MODS', true );
Exigir SSL para Admin e Logins
Nota: WordPress versão 4.0 obsoleta FORCE_SSL_LOGIN. Use FORCE_SSL_ADMIN.
FORCE_SSL_ADMIN é para quando você deseja proteger os logins e a área de administração para que as senhas e os cookies nunca sejam enviados em claro. Veja também Administration_Over_SSL para mais detalhes.
define( 'FORCE_SSL_ADMIN', true );
Bloquear solicitações de URL externas
Bloqueie solicitações de URL externas definindo WP_HTTP_BLOCK_EXTERNAL como verdadeiro e isso só permitirá que localhost e seu blog façam solicitações. A constante WP_ACCESSIBLE_HOSTS permitirá que hosts adicionais passem por solicitações. O formato da constante WP_ACCESSIBLE_HOSTS é uma lista separada por vírgulas de nomes de host para permitir, domínios curinga são suportados, por exemplo, * .wordpress.org permitirá que todos os subdomínios do wordpress.org sejam contatados.
define( 'WP_HTTP_BLOCK_EXTERNAL', true ); define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.github.com' );
Desativar atualizações automáticas do WordPress
Pode haver motivo para um site não ser atualizado automaticamente, como personalizações ou atualizações fornecidas pelo host. Isso também pode ser feito antes de uma versão principal para permitir tempo para teste em um ambiente de desenvolvimento ou preparação antes de permitir a atualização em um site de produção.
define( 'AUTOMATIC_UPDATER_DISABLED', true );
Desativar atualizações principais do WordPress
A maneira mais fácil de manipular as atualizações principais é com a constante WP_AUTO_UPDATE_CORE:
# Desative todas as atualizações principais: define( 'WP_AUTO_UPDATE_CORE', false ); # Habilite todas as atualizações principais, incluindo secundárias e principais: define( 'WP_AUTO_UPDATE_CORE', true ); # Habilita atualizações básicas para versões secundárias (padrão): define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Referência: Desativando atualizações automáticas no WordPress 3.7
Edição de imagens de limpeza
Por padrão, o WordPress cria um novo conjunto de imagens cada vez que você edita uma imagem e quando você restaura o original, ele deixa todas as edições no servidor. Definir IMAGE_EDIT_OVERWRITE como verdadeiro altera esse comportamento. Apenas um conjunto de edições de imagem é criado e quando você restaura o original, as edições são removidas do servidor.
define( 'IMAGE_EDIT_OVERWRITE', true );
Verifique duas vezes antes de salvar
Certifique-se de verificar os espaços iniciais e / ou finais em torno de qualquer um dos valores acima inseridos e NÃO exclua as aspas simples!
Antes de salvar o arquivo, certifique -se de verificar novamente se você não excluiu acidentalmente nenhuma das aspas simples em torno dos valores dos parâmetros. Certifique-se de que não haja nada após a tag PHP de fechamento no arquivo. A última coisa no arquivo deve ser ?> E nada mais. Sem espaços.
Para salvar o arquivo, escolha Arquivo> Salvar como> wp-config.php e salve o arquivo na raiz da instalação do WordPress. Carregue o arquivo em seu servidor web e você estará pronto para instalar o WordPress!