Codex

Interested in functions, hooks, classes, or methods? Check out the new WordPress Code Reference!

pt-br:Editando wp-config.php


cb-help.png
Artigo parcialmente traduzido ou que precisa de tradução
Este documento está parcialmente traduzido ou precisa ser traduzido. Toda a tradução é feita por voluntários e você pode ser um deles.
ParticiparArtigos para traduzirFórum de SuporteTodos os Artigos
WARNING: Antes de editar esta página

Não use suas informações verdadeiras de MySQL

Como parte da instalação do WordPress, você deve modificar o arquivo wp-config.php para informar o WordPress sobre as configurações de acesso para o banco de dados MySQL do seu site.

Introdução

Pode parecer estranho, mas o arquivo wp-config.php não existe em nenhuma cópia baixada por http://wordpress.org/. Você precisa criar o arquivo! O wp-config-sample.php é provido como um exemplo de como ele trabalha. As configurações mais avançadas serão vistas mais adiante, nesse mesmo artigo.

Para mudar o arquivo wp-config.php da sua instalação, você vai precisar dessa informação.

Nome do Banco de Dados 
Esse é o nome do Banco de Dados que você quer que o WordPress use.
Usuário do Banco de Dados 
O nome de usuário usado para que o WordPress acesse o banco. Você pode criar um pelo cPanel do sue host ou equivalente.
Senha do Banco de Dados 
Senha usada pelo usuário para acessar o banco.
Database Host 
O nome do host que hospeda o servidor MySQL.

Se seu serviço de hospedagem instalou o WordPress para você, obtenha essas informações dele. Caso você gerencie seu próprio servidor web ou conta de hospedagem, você provavelmente já tem essa informação.

Configurando o Banco de Dados

Importante: Jamais use um editor de texto como o Microsoft Word/Open Office para editar arquivos do WordPress! Use editores de texto plano, um bom editor seria Notepad++ (no Windows) ou o TextEdit (no Mac OS).

Localize o arquivo wp-config-sample.php no diretório-base da sua instalação e o abra em um editor de texto plano, Notepad++ (no Windows) ou o TextEdit (no Mac OS).

NOTE: Desde a Version 2.6, wp-config.php pode ser movido para outro diretório diferente do WordPress.

wp-config-sample.php padrão

Esse é um exemplo do wp-config-sample.php padrão. Os valores aqui são exemplos para lhe mostrar como se faz. Você precisa fazer as mudanças no seu próprio website, não aqui. Se você efetuar mudanças usando a edição, isso não irá funcionar e você irá expor informações de senha para todo o mundo.

// ** Configurações do MySQL - Você pode pegar essas informações com o serviço de hospedagem ** //
/** O nome do banco de dados do WordPress */
define('DB_NAME', 'nomedoBD');

/** Usuário do banco de dados MySQL */
define('DB_USER', 'usuarioMySQL');

/** Senha do banco de dados MySQL */
define('DB_PASSWORD', 'senha');

/** nome do host do MySQL */
define('DB_HOST', 'localhost');
NOTE: Textos dentro de /* */ ou após de // ou # são comentários, apenas para propósitos informativos.
NOTE: Não mude os detalhes aqui editando essa página, mude no seu próprio servidor web.

Definindo o nome do Banco de Dados

Substitua nomedoBD (mais exatamente na linha 19) pelo nome do Banco de Dados, como, por exemplo, wordpress. Assim, a linha 19 torna-se:

define('DB_NAME', 'wordpress'); //Legal, não? Agora, na linha 19, temos no nome do DB :)

Definindo o nome do usuário do Banco de Dados

Substitua usuarioMySQL, na linha 22, pelo usuário do banco de dados do WordPress. Tomamos, como exemplo, usuario_wordpress:

define('DB_USER', 'usuario_wordpress'); //Sabia que isso pode representar mais de meio caminho andado?

Definindo a senha do nome de usuário do Banco de Dados

Substitua senha, na linha 25, pela senha do usuário. A nossa senha será eu_adoro_wordpress:

define('DB_PASSWORD', 'eu_adoro_wordpress'); //Nossa, sabia que isso pode ter acabado por aqui? Se não, continue lendo!
AVISO: NÃO utilizem os valores aqui demonstrados em suas instalações. Embora o WordPress seja seguro por natureza, utilizar os valores escritos aqui se revelam como uma bela vulnerabilidade.

Definindo o host do Banco de Dados

Substitua localhost, na linha 28, pelo host do seu servidor MySQL.

NOTE: As chances que você precise mudar essa linha são praticamente nulas. Tente instalar com o valor padrão localhost. Caso falhe, contate seu host.

Contando com essa nota, caso seja necessário, a linha 28 pode ficar assim:

define('DB_HOST', 'sqlserver.news.wordpress.org'); //Não se esqueçam que isso é um exemplo!

Possíveis valores para DB_HOST

Diferentes companhias de hospedagens usam configurações de rede diferentes para suas Bases de Dados. Se sua companhia está listada na coluna à esquerda, provavelmente o valor correto para DB_HOST deve se parecer com o que está na coluna à direita. Contate o suporte técnico e/ou procure na documentação on-line da sua companhia.

Companhia de Hospedagem Provável valor para DB_HOST
1and1 db12345678
AN Hosting localhost
A Small Orange localhost
BlueHost localhost
DreamHost mysql.seu-dominio.com
GoDaddy h41mysql52.secureserver.net
HostGator localhost
HostICan localhost
ICDSoft localhost:/tmp/mysql5.sock
LaughingSquid localhost
MediaTemple GridServer internal-db.s44441.gridserver.com
one.com localhost
pair Networks dbnnnx.pair.com
Rackspace Cloud mysql50-01.wc1.dfw1.stabletransit.com
Yahoo mysql
Hosts with cPanel localhost
Hosts with Plesk localhost
Hosts with DirectAdmin localhost
Tophost.it sql.your-domain-name.it



Portas Alternativas para o MySQL

Se seu serviço de hospedagem usar uma porta para o MySQL diferente de 3306 (o que é o valor padrão), você precisa incluir essa modificação no DB_HOST, dentro do seu wp-config.php, para que ele reflita as configurações da sua hospedagem. Apenas insira a porta logo após o host, seperando-os por : (dois pontos). Isso tudo fica assim:

Caso seja localhost

define('DB_HOST', 'localhost:3307');

Ou seja num servidor externo

define('DB_HOST', 'sqlserver.news.wordpress.org:3307');

Substitua 3307 pelo número que seu host lhe informar.

Charset do Banco de Dados

Aparecendo a partir da Version 2.2], DB_CHARSET tornou-se disponível para permitir a definição do charset do Banco de Dados, como por exemplo, latin1 para bancos de dados que "falam" português.

mysqlCharset.png

Dependendo a configuração do servidor MySQL, o charset padrão pode ser latin1 ou UTF-8. Não importando o caso, normalmente, UTF-8 (Unicode UTF-8) quase sempre se sai como a melhor opção. O UTF-8 é internacional e funciona com várias línguas

Esse é um exemplo de como tudo fica:

define('DB_CHARSET', 'utf8');
WARNING: Para as novas instalações:

Não é usual encontrar uma razão forte o suficiente para alterar o valor de DB_CHARSET. Se seu blog necessitar de um charset diferente, por favor, leia a Documentação do MySQL: Character Sets and Collations MySQL Supports (em inglês) para descobrir valores válidos para DB_CHARSET.

WARNING: Para aqueles que executam atualizações, especialmente após a versão 2.2.

Caso DB_CHARSET e DB_COLLATE não existam em seu wp-config.php, antes de tudo, leia Converting Database Character Sets. Adicionar DB_CHARSET e DB_COLLATE para o wp-config.php, para um blog existente, é capaz de quebrar a instalação.

Collation do Banco de Dados

A partir da Versão 2.2 do WordPress, o DB_COLLATE foi disponibilizado para permitir a designação do collation banco de dados (ou seja, a ordem de classificação do conjunto de caracteres). Na maioria dos casos, este valor pode ser deixado em branco (nulo), então o collation do banco de dados será automaticamente atribuído pelo MySQL baseado no charset (character set) do banco de dados especificado pelo DB_CHARSET. Configure DB_COLLATE para um dos valores UTF-8 definidos em UTF-8 character sets para maioria das linguagens da Europa Ocidental.

The WordPress default DB_COLLATE value:

define('DB_COLLATE', ); 

UTF-8 Unicode General collation

define('DB_COLLATE', 'utf8_general_ci');

UTF-8 Unicode Turkish collation

define('DB_COLLATE', 'utf8_turkish_ci');
WARNING: Those performing new installations

There usually should be no reason to change the default value of DB_COLLATE. Leaving the value blank (null) will insure the collation is automatically assigned by MySQL when the database tables are created.

WARNING: Those performing upgrades (especially blogs that existed before 2.2)

If DB_COLLATE and DB_CHARSET do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. And you may be in need of a WordPress upgrade.


Chaves de Segurança

Criadas para trazer mais segurança, as chaves são usadas para incriptar cookies criados pelo WordPress.

Você não tem que se lembrar das chaves, apenas crie chaves longas, aleatórias e complicadas - ou melhor ainda, use o Gerador de Chaves. Você pode mudar estas chaves a qualquer momento para invalidar todos os cookies existentes. Isto significa que todos os usuários terão que se autenticar novamente.

Exemplo (não use essas chaves!):

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%%');

A secret key makes your site harder to hack and access harder to crack by adding random elements to the password.

In simple terms, a secret key is a password with elements that make it harder to generate enough options to break through your security barriers. A password like "password" or "test" is simple and easily broken. A random, unpredictable password such as "88a7da62429ba6ad3cb3c76a09641fc" takes years to come up with the right combination. A 'salt is used to further enhance the security of the generated result.

The four keys are required for the enhanced security. The four salts are recommended, but are not required, because WordPress will generate salts for you if none are provided. They are included in wp-config.php by default for inclusiveness.

For more information on the technical background and breakdown of secret keys and secure passwords, see:

Opções Avançadas

The following sections may contain advanced / unsupported information, so please make sure you practice regular backups and know how to restore them before experimenting on a production installation.

table_prefix

The $table_prefix is the value placed in the front of your database tables. Change the value if you want to use something other than wp_ for your database prefix. Typically this is changed if you are installing multiple WordPress blogs in the same database.

// You can have multiple installations in one database if you give each a unique prefix
$table_prefix  = 'r235_';   // Only numbers, letters, and underscores please!

A second blog installation using the same database can be achieved simply by using a different prefix than your other installations.

$table_prefix  = 'y77_';   // Only numbers, letters, and underscores please!

WordPress address (URL)

WP_SITEURL, defined since WordPress Version 2.2, allows the WordPress address (URL) to be defined. The valued defined is the address where your WordPress core files reside. It should include the http:// part too. Do not put a slash "/" at the end. Setting this value in wp-config.php overrides the wp_options table value for siteurl and disables the WordPress address (URL) field in the Administration > Settings > General panel.

NOTE: It won't change the Database value though, and the url will revert to the old database value if this line is removed from wp-config. Use the RELOCATE constant to change the siteurl value in the database.

If WordPress is installed into a directory called "wordpress" for the domain example.com, define WP_SITEURL like this:

define('WP_SITEURL', 'http://example.com/wordpress');

Dynamically set WP_SITEURL based on $_SERVER['HTTP_HOST']

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpressp');
NOTE: A safer alternative for some installations would be to use the server-generated SERVER_NAME instead of the php/user-generated HTTP_HOST which is created dynamically by php based on the value of the HTTP HOST Header in the request, thus possibly allowing for file inclusion vulnerabilities. SERVER_NAME is set by the server configuration and is static.

Dynamically set WP_SITEURL based on $_SERVER['SERVER_NAME']

define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpressp');

Blog address (URL)

WP_HOME is another wp-config.php option added in WordPress Version 2.2. Similar to WP_SITEURL, WP_HOME overrides the wp_options table value for home but does not change it permanently. home is the address you want people to type in their browser to reach your WordPress blog. It should include the http:// part and should not have a slash "/" at the end.

define('WP_HOME', 'http://example.com/wordpress'); 

If you are using the technique described in Giving WordPress Its Own Directory then follow the example below. Remember, you will also be placing an index.php in your web-root directory if you use a setting like this.

define('WP_HOME', 'http://example.com');

Dynamically set WP_HOME based on $_SERVER['HTTP_HOST']

define('WP_HOME',    'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');

Movendo wp-content

Since Version 2.6, you can move the wp-content directory, which holds your themes, plugins, and uploads, outside of the WordPress application directory.

Set WP_CONTENT_DIR to the full local path of this directory (no trailing slash), e.g.

define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );

Set WP_CONTENT_URL to the full URI of this directory (no trailing slash), e.g.

define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');

Optional
Set WP_PLUGIN_DIR to the full local path of this directory (no trailing slash), e.g.

define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

Set WP_PLUGIN_URL to the full URI of this directory (no trailing slash), e.g.

define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');

If you have compability issues with plugins Set PLUGINDIR to the full local path of this directory (no trailing slash), e.g.

define( 'PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );

Modify AutoSave Interval

When editing a post, WordPress uses Ajax to auto-save revisions to the post as you edit. You may want to increase this setting for longer delays in between auto-saves, or decrease the setting to make sure you never lose changes. The default is 60 seconds.

define('AUTOSAVE_INTERVAL', 160 );  // seconds

Post Revisions

WordPress, by default, will save copies of each edit made to a post or page, allowing the possibility of reverting to a previous version of that post or page. The saving of revisions can be disabled, or a maximum number of revisions per post or page can be specified.

Desativando Revisão de Posts

Caso você não defina esse valor, o WordPress automaticamente torna WP_POST_REVISION para true, o que ativa a revisão. Se você deseja desativar isso, use a linha a seguir:

define('WP_POST_REVISIONS', false );

Especificando um número de revisões por post

Se você deseja especificar um número máximo de revisões, torne false/true para um número, como 5 ou 3.

define('WP_POST_REVISIONS', 3);

Set Cookie Domain

The domain set in the cookies for WordPress can be specified for those with unusual domain setups. One reason is if subdomains are used to serve static content. To prevent WordPress cookies from being sent with each request to static content on your subdomain you can set the cookie domain to your non-static domain only.

define('COOKIE_DOMAIN', 'www.askapache.com');

Ativar Multisite / Ativar Rede WordPress

WP_ALLOW_MULTISITE é um recurso introduzido no WordPress 3.0 para permitir a criação de subsites, antes possível com o software extinto WordPress MU.

define('WP_ALLOW_MULTISITE', true);

Debug

The WP_DEBUG option, added in WordPress Version 2.3.1, controls the display of some errors and warnings. If this setting is absent from wp-config.php, then the value is assumed to be false.

NOTE: The true and false values in the example are not set in apostrophes (') because they are boolean values.
define('WP_DEBUG', true);
define('WP_DEBUG', false);

Additionally, if you are planning on modifying some of WordPress' built-in JavaScript, you should enable the following option:

define('SCRIPT_DEBUG', true);

This will allow you to edit the scriptname.dev.js files in the wp-includes/js and wp-admin/js directories.

In WordPress versions since 2.3.2, database errors are printed only if WP_DEBUG is set to true. In earlier versions, database errors were always printed. (Database errors are handled by the wpdb class and are not affected by PHP's error settings.)

In WordPress version 2.5, setting WP_DEBUG to true also raises the error reporting level to E_ALL and activates warnings when deprecated functions or files are used; otherwise, WordPress sets the error reporting level to E_ALL ^ E_NOTICE ^ E_USER_NOTICE.

Disable Javascript Concatenation

To result in a faster administration area, all Javascript files are concatenated into one URL. If Javascript is failing to work in your administration area, you can try disabling this feature:

define('CONCATENATE_SCRIPTS', false);

Configure Error Log

Because wp-config.php is loaded for every page view not loaded from a cache file, it is an excellent location to set php ini settings that control your php installation. This is useful if you don't have access to a php.ini file, or if you just want to change some settings on the fly.

Here is an example that turns php error_logging on and logs them to a specific file. If WP_DEBUG is defined to true, the errors will also be saved to this file. Just place this above any require_once or include commands.

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/example.com/logs/php_error.log');
/* That's all, stop editing! Happy blogging. */

Another example of logging errors, as suggested by Mike Little on the wp-hackers email list:

/**
 * This will log all errors notices and warnings to a file called debug.log in
 * wp-content (if Apache does not have write permission, you may need to create
 * the file first and set the appropriate permissions (i.e. use 666) ) 
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

Aumentando a memória alocada para PHP

A constante WP_MEMORY_LIMIT permite especificar a quantidade máxima de memória que pode ser consumida pelo PHP em seus ervidor. Esta configuração pode ser necessária no caso de receber mensagens como "Allowed memory size of xxxxxx bytes exhausted".

Essa configuração aumenta a memória do PHP apenas para o WordPress não para outras aplicações. Por padrão, o WordPress tenta aumentar a memória alocada para PHP para 32MB (o código está no início do arquivo wp-settings.php), de modo que o ajuste em' wp-config.php deve refletir algo maior que 32MB.

O WordPress irá verificar automaticamente se foi atribuída menos memória ao PHP do que o valor digitado, antes de usar esta função. Por exemplo, se o PHP está alocando 64MB, não há necessidade de definir esse valor para 64M já que o WordPress usará automaticamente todo o 64MB, se necessário.

Nota: essa configuração pode não funcionar se o seu serviço de hospedagem não permite aumentar o limite de memória do PHP - nesse caso, entre em contato com seu serviço para aumentar o limite de memória do PHP. Além disso, observe que muitos serviços definem o limite de memória PHP em 8MB.

Constante para aumentar a memória para o PHP em 64MB:

define('WP_MEMORY_LIMIT', '64M');

Constante para aumentar a memória para o PHP em 96MB:

define('WP_MEMORY_LIMIT', '96M');

Cache

The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.

define('WP_CACHE', true);

Custom User and Usermeta Tables

CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designated that the user and usermeta tables normally utilized by WordPress are not used, instead these values/tables are used to store your user information.

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

Idioma e Diretório de Idioma

WPLANG define o nome do arquivo de tradução(.mo) do idioma. WP_LANG_DIR define em qual pasta o arquivo .mo está. Se WP_LANG_DIR não estiver definido, o WordPress primeiramente vai procurar por arquivos de idiomas em wp-content/languages e então em wp-includes/languages pelos arquivos .mo definidos pelo arquivo WPLANG.

define('WPLANG', 'pt_BR');
define('WP_LANG_DIR', $_SERVER['DOCUMENT_ROOT'].'wordpress/languages');

Save queries for analysis

The SAVEQUERIES definition saves the database queries to a array and that array can be displayed to help analyze those queries. The information saves each query, what function called it, and how long that query took to execute.

NOTE: This will have a performance impact on your site, so make sure to turn this off when you aren't debugging.

First, put this in wp-config.php:

define('SAVEQUERIES', true);

Then in the footer of your theme put this:

<?php
if (current_user_can('administrator')){
    global $wpdb;
    echo "<pre>";
    print_r($wpdb->queries);
    echo "</pre>";
}
?>

Override of default file permissions

The FS_CHMOD_DIR and FS_CHMOD_FILE define statements allow override of default file permissions. These two variables were developed in response to the problem of the core update function failing with hosts (e.g. some Italian hosts) running under suexec. If a host uses restrictive file permissions (e.g. 400) for all user files, and refuses to access files which have group or world permissions set, these definitions could solve the problem. Note that the '0755' is an octal value and is not delineated with single quotes ('). See Also: Changing File Permissions

define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));

Constantes de Atualização WordPress

Você deve definir algumas das contantes abaixo para corrigir problemas de atualização.

As causas mais comuns da necessidade de definir isto são:

  • HServidor correndo com uma configuração de instalação especial envolvendo Symlinks, você pode precisar para definir as constantes relacionadas a caminhos (FTP_BASE, FTP_CONTENT_DIR, e FTP_PLUGIN_DIR), muitas vezes definir só a base é suficiente.
  • Certas instalações PHP são entregues com uma extensão de FTP PHP incompatível com certos servidores FTP, nestas raras situações pode ser necessário definir FTP_METHOD em'ftpsockets'

A seguir, estão as constantes válidas para atualizações do WordPress:

  • FS_METHOD obriga o método do sistema de arquivos. Deve ser "direct", "ssh", "ftpext", ou "ftpsockets". Geralmente, você deve apenas mudar isso se estiver enfrentando problemas de atualização, se mudar, e não adiantar mude de volta/remova, Na maioria das circunstâncias, definir ftpsockets vai funcionar se o método escolhido automaticamente não funcionar.
    • (Primary Preference) "Direct" obriga a usar solicitações Direct File I/O de dentro do PHP, o que possui muitas questões de segurança em servidores mal configurados, pode ser escolhido automaticamente quando necessário.
    • (Secondary Preference) "ssh" obriga a usar a extensão SSH PHP.
    • (3rd Preference) "ftpext" obriga a usar a extensão FTP PHP para acesso FTP e finalmente:
    • (4th Preference) "ftpsockets" usa classe de Sockets PHP para acesso FTP.
  • FTP_BASE é o caminho completo para a pasta "base"(ABSPATH) da instalação WordPress.
  • FTP_CONTENT_DIR é o caminho completo para a pasta wp-content da instalação WordPress.
  • FTP_PLUGIN_DIR é o caminho completo para a pasta plugin da instalação WordPress.
  • FTP_PUBKEY é o caminho completo para sua chave SSH pública.
  • FTP_PRIKEY é o caminho completo para sua chave SSH particular.
  • FTP_USER usa o nome de usuário FTP ou SSH. Muito provavelmente são os mesmos, mas use o mais adequado para o tipo de atualização que deseja fazer.
  • FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication this can be omitted.
  • FTP_HOST is the hostname:port combination for your SSH/FTP server. The default FTP port is 21 and the default SSH port is 22, These do not need to be mentioned.
  • FTP_SSL TRUE for SSL-connection if supported by the underlying transport, Not available on all servers. This is for "Secure FTP" not for 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);

Ativando Acesso a Atualização SSH

Para habilitar SSH2 como uma opção de atualização, você precisará instalar a extensão SSH2 pecl. Para instalar esta biblioteca, terá de emitir um comando semelhante ao seguinte, ou fale com o seu provedor de hospedagem web para ter isso:

pecl install ssh2

Depois de instalar a extensão ssh2 pecl, você precisará modificar sua configuração do PHP para carregar automaticamente essa extensão.

PECL é fornecido pelo pacote pearl na maioria das distribuições linux. Para instalar em pecl no Redhat/Fedora/CentOS:

yum -y install php-pear

To install pecl in Debian/Ubuntu:

apt-get install php-pear

É recomendado o uso de uma chave privada que não é protegida com pass-phrase. Há inúmeros relatos que chaves protegidas privadas pass-phrase não funcionam corretamente. Se você decidir tentar uma pass-phrase protegidas chave privada, você precisará digitar a frase secreta para a chave privada como FTP_PASS ou inserindo-o no campo "Password" no campo de credencial apresentada ao instalar atualizações.

Se ainda não está claro sobre como usar o SSH para atualizar ou instalar o WordPress/plugins, veja este tutorial(em inglês).

Cron Alternativo

Use isto, por exemplo, se postagens agendadas não estiverem sendo publicadas. De acordo com a explicação neste tópico de forum (em inglês), "este método alternativo utiliza uma abordagem de redirecionamento, o que faz o navegador dos usuários obterem um redirecionamento quando o cron precisa ser executado, para que eles voltem para o local imediatamente, enquanto o cron continua a funcionar no link descartado. Este método é um pouco duvidoso, às vezes, é por isso que não é o padrão."

define('ALTERNATE_WP_CRON', true);

Constantes Definidas Adicionais

Aqui estão constantes adicionais que podem ser definidas, mas provavelmente não devem ser. As definições de cookies são 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('DISABLE_WP_CRON', true);

Esvaziar a Lixeira

Esta constante controla o número de dia antes do WordPress excluir postagens, páginas, anexos e comentários excluídos definitivamente. O padrão é 30 dias.

define('EMPTY_TRASH_DAYS', 30 );  // 30 dias

Para desativar este perído, você pode zerar o número de dias e assim não armazenar dados da lixeira. Atenção, o WordPress não pede confiramção quando se exclui permanentemente.

define('EMPTY_TRASH_DAYS', 0 );  // zero dias

Otimização automática do Banco de Dados

Desde a Versão 2.9, há otimização automática do banco de dados que você pode ativar adicionando a seguinte definição ao seu arquivo wp-config.php somente quando o recurso é necessário.

 define('WP_ALLOW_REPAIR', true);

Visite {$your_site}/wp-admin/maint/repair.php para iniciar o processo de otimização.

Nota Isso ativa a funcionalidade, Não é necessário fazer login ára ativar esta funcionalidade. Isso é porque na maioria das vezes não é possível se logar quando o banco de dados estiver corrompido.

Não permitir atualização global de tabelas

O DO_NOT_UPGRADE_GLOBAL_TABLES define previne dbDelta() e as funções de upgrade de fazerem consultas exageradas a tabelas globais.

Sites que possuem grandes tabelas global (em especial os usuários e usermeta), bem como sites que compartilham tabelas de usuários com bbPress e outros, pode impedir a atualização de alterar as tabelas durante a atualização definindo DO_NOT_UPGRADE_GLOBAL_TABLES.

Desde que ALTER, ou um ilimitado DELETE ou UPDATE, pode demorar bastante para concluir, sites grande geralmente quer evitar estes de rodarem como parte do upgrade, para que sejam gerenciados manualmente. Além disso, se as instalações estão compartilhando as tabelas de usuário entre múltiplos bbPress e WordPress instalações, talvez seja necessário querer um site para ser o mestre de atualização.

  define('DO_NOT_UPGRADE_GLOBAL_TABLES', true);

Vizualizar 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());

Verificando antes de Salvar

Certifique-se de verificar e remover espaços antes de qualquer um dos valores acima inseridos, e não exclua as aspas simples !

Antes de salvar o arquivo, certifique-se de verificar que não tenha apagado acidentalmente alguma das aspas simples em torno dos valores dos parâmetros. Certifique-se que não há nada após a tag de fechamento PHP no arquivo. A última coisa no arquivo deve ser ?> e nada mais. Sem espaços.

Para salvar o arquivo, salve o arquivo na raiz da instalação do WordPress. Faça o upload do arquivo para o seu servidor web.

Veja Também