Por muitas vezes, quando era iniciante no Magento, ficava diante de uma pasta ou arquivo que pareciam inúteis para o funcionamento e pesquisando também percebi que essa é uma dúvida frequente por quem mantém uma loja em Magento. Penando nisso resolvi escrever este pequeno artigo para desmistificar as principais pastas do Magento e o que pode ser apagado. Lembrando que essas mesmas pastas existem em todas as versões do Magento acima da 1.4, isso não vale para o Magento 2 que segue uma nova estrutura;
Aqui vai a lista do que pode ser apagado, porque caso seja o próprio magento irá recria as pastas automaticamente e mais abaixo dou uma rápida explicação do porquê pode ser apagada e seu efeito na loja
- media/catalog/product/cache
- var/cache
- var/log
- var/report
- var/session
Agora que você já sabe quais pastas podem ser deletadas entenda porque você pode precisar apagar essas pastas:
media/catalog/product/cache
Aqui ficam as imagens dos produtos usadas pela loja, mas não as originais, aqui estão as imagens redimensionadas pelo tema, então quando se você testar vários temas em sua loja, inevitavelmente você vai ter a pasta media/catalog/product/cache muito cheia e, dependendo da quantidade de variações que seu tema gera ela pode ficar muito pesada, você pode ter o efeito parecido indo no admin do Magento em Sistema > Configurações > Gerenciar Cache e clicando no botão “Liberar cache das imagens do Catálogo”, mas deletar essa pasta é mais rápido e efetivo.
var/cache
Na pasta var/cache fica todo o cache gerado pelo Magento tanto no frontend quanto no backend, o equivalente no admin é também em gerenciar cache e limpar todos os caches ou nos botões “Liberar cache do Magento” ou “Liberar cache Armazenado”, novamente deletar essa pasta é mais rápido e efetivo.
var/log
A pata var/log normalmente não existirá em uma loja em produção ou não gerará problemas, mas pode ser uma dor de cabeça caso sua loja esteja tendo erros de funcionamento ocultos pelo servidor, tais erros são salvos em var/log/arquivo.log que pode ficar acumulando por anos até que os arquivos de erro sejam tão grandes que ocupem todo o espaço do servidor e sua loja pare de funcionar. o ideal nesse caso é resolver o problema e manter o log do magento desligado, o log do maento deve ser ativado somente em desenvolvimento ou para correções de erro. se não é esse o caso delete essa pasta.
var/report
A pasta var/report é parecida com a var/log porém ela é usada pelo Magento quando há um travamento que mostra a famosa tela de erro do Magento que não mostra o erro de fato, o erro fica salvo em um arquivo que não tem extensão, somente uma sequência de números aleatórios, mas nesse arquivo contém o erro e toda a sequência que levou a tela de erro. Durante o desenvolvimento ou se uma erro acontece na loja em produção, devido a varias pessoas entrando no site e vendo o mesmo erro e assim gerando mais arquivos de erro, essa pasta pode, também, lotar de arquivos, mas pode apagar sem medo.
var/session
A pasta var/session é responsável por gerar um arquivo que identifica uma sessão aberta na loja Magento, seja um visitante, um cliente ou até mesmo você acessando o admin da loja. a pata var/session existe apenas nas lojas onde na instalação ou no arquivo app/etc/local.xml especificou para salvar as sessões da loja em arquivo ao invés de salvar no banco de dados, o que poderia ser uma moa ideia já que assim evitaria dezenas de requisições no banco, porém ficou mais comum os servidores bloquearem o funcionamento da loja quando essa chega a mais de 200 mil arquivos dentro do sistema e isso é um problema porque, dependendo da visitação da sua loja, esse total pode ser alcançado em duas ou três horas de funcionamento. Outro problema comum gerado por essa pasta é quando não se consegue mais logar na loja tanto como cliente quanto como admin, isso porque a pasta chegou ao limite de arquivos suportados. Se esse for o caso, você precisará deletar essa pasta com tudo, isso fará com que todas as sessões da loja sejam encerradas e deverá voltar ao normal. Obs.: se essa pasta lota com frequência você deverá alterar a configuração de sessões de flie para db no arquivo local.xml.
Então é isso, duvidas deixem um comentário, um abraço e até a próxima.
Você também vai gostar:
- Sete dicas que deixarão sua loja Magento mais segura
- 7 fontes perfeitas para design minimalista totalmente free
- GET base url, skin url, media url, js url, store url e current url
- Como reindexar o Magento fora do admin (via ssh)
- Como personalizar o campo Select apenas com CSS
- Magento 2 comandos – principais commands e suas utilizações
Respostas de 3
Estou gostando muito das suas publicações, mas ainda tenho uma dúvida, duas na verdade.
Qual seria a vantagem de iniciar uma loja, nova, com magento 1.9?
E tem algum módulo de marketplace para me indicar?, para uma loja pequena, estou achando todos muito caros.
Oi, vantagem no Magento 1.9 é que tem muito material disponível, mas a versão 1 não terá mais suporte a partir de 2020, se é uma loja nova, seria uma boa cogitar em fazer no Magento 2.
Módulo marketplace não conheço nenhum satisfatório, os gratuitos são muito ruins e mesmo os pagos não atendem as demandas que já recebi.
Oi João, tudo bem?
Olha, o Magento 1.9 acabou o suporte como dito pelo Ronaldo, no entanto, há uma fork (modificação) dele, chamado OpenMage, que é compatível com praticamente todos os módulos Magento 1.9, inclusive os que eu tinha instalados desde do 1.6, funcionam.
Segui um tutorial de atualização do próprio Ronaldo e migrei para o OpenMage, apesar de ter feito um site lindo no Magento 2.
Motivo? Performance! Magento 2 é muito lento e pra ter uma velocidade aceitável, é necessário pagar uma hospedagem caríssima. Eu vou criar alguns vídeos falando sobre OpenMage, assim que terminar os testes. Basta pesquisar por “Migrando do Magento 1.9 para OpenMage” este será meu primeiro video.