Tomando Aspectos do WordPress para Concedidos

Devido à natureza de código aberto do WordPress, um dos luxos que muitos de nós estão acostumados a ter é o controle total sobre o ambiente em que estamos trabalhando. Dado isso, você pode até dizer que tomamos certos aspectos do WordPress como garantidos.

E eu diria que para a maioria dos projetos em que trabalhamos, isso é verdade.

Com isso, quero dizer que não apenas podemos personalizar, estender e até limitar o software (para certos tipos de usuários), mas também podemos alterar certos aspectos de sua configuração.

Mas se você trabalha para outros – um empregador, como parte de um empreiteiro ou em alguma outra situação – você pode estar limitado na quantidade de personalização que pode fazer.

Tomando aspectos do WordPress para concedido (e como evitá-lo)

Caso em questão: Ontem, escrevi sobre como você pode modificar os códigos de acesso para o Pods Framework usando um filtro em vez de uma de suas tags mágicas.

Para reiterar, acho que o Pods é poderoso e acho que a equipe por trás dele não apenas faz um bom trabalho ao construir o que eles forneceram, mas também faz um ótimo trabalho ao gerenciar sua comunidade.

Isso é evidente em seus fóruns e no Twitter. Jim True, líder de suporte e gerente de projeto, me ligou logo após publicar a postagem:

Na maioria das vezes, gosto quando as organizações se envolvem de forma proativa com seus usuários, e este é um exemplo de caso.

Mas também demonstra outro ponto: havia um luxo no WordPress que eu estava acostumado a ter. Especificamente, ser capaz de modificar o arquivo de configuração conforme necessário, que o projeto no qual eu estava trabalhando eu não podia pagar.

Então eu tive que encontrar uma solução alternativa (e, portanto, escrevi sobre isso). Isso é um golpe contra o WordPress? Não. Um cliente? De jeito nenhum. Pods? Não.

O que consideramos certo

É simplesmente um lembrete de que pode haver coisas no WordPress que damos como garantidas.

Mas também é um lembrete de que existem outras maneiras de resolver os problemas. Claro, você pode argumentar que não são soluções ideais, mas quando você está fornecendo uma solução para um cliente que funciona, é bem codificada e documentada, não é ruim. É apenas diferente.

E essa é a próxima melhor coisa.