Adicionar Cache em diversos locais onde o desempenho é importante, como consultas complexas ou de alto desempenho.
Por exemplo a listagem de Produtos de uma Categoria.
Porém tem que ser limpo de forma automática de preferência ao editar um Produto, Categoria, em resumo seria acionado a limpeza de uma parte do Cache quando feita uma mudança, por isso seria bom separar o cache das Categorias, Produtos, entre outros importantes, mas não acho que deva cobrir todas funções, apenas as consultas e as que realmente precisam inicialmente.

Também seria bom usar uma boa biblioteca, para ter a opção de escolher cache em arquivo, Banco de Dados ou Memória como Memcached.

Colocar um Sistema de log mais completo, para uso geral.
Seja para pequenos testes ou marcar certos passos para módulos ou alguns recursos.
Também poderia ser adicionado testes, mas nessa parte não uso nenhum Sistema de Teste, costumo usar mais o Firephp acompanhando pelo Log.
No Opencart oficial não vi nada relacionado para testes, parece que não focaram nesse ponto, mas para um grande projeto pode ser fundamental, pequenos sistemas ou módulos, é fácil testarmos com log ou em tempo real, mas projetos grandes sempre vai ser difícil cobrir todos os pontos.

O Firephp https://github.com/firephp/firephp-core , ponto fraco que depende do Firefox e tem hospedagem que trava ao por ele, mesmo sem uso, pelo menos nos testes que fiz.
Outro interessante http://firelogger.binaryage.com/
Esses são mais para testes, usado mais como debug. Para avisos e outros casos, teria que usar outros.

A estrutura não precisa ser exatamente como no print, eu desenvolvi este modelo ao longo do tempo, mas a idéia é separar pelo menos o opencart original dentro de app/ e chamaremos de "core" ele não será alterado quando for pegar o "novo opencart" para desenvolver algum ecommerce. Ele sera atualizado via composer. A versão que iremos pegar do opencart será discutida em outra issue. Outra idéia da nova estrutura é a extensions/ folder onde obviamente ira ficar nossas extensões e a pasta themes onde ficará os temas, do resto podemos ou não segui a estrutura do print. Deem suas opiniões.

app/ Contém o core do opencart
configs/ Configurações gerais
extensions/ Extensões
image/ Imagens
storage/ Cache, logs e arquivos temporários
themes/ Temas
vendor/ composer vendor

Acho importante em termos de performance e oferecer a oportunidade de fazer módulos já na nova e melhor versão do PHP

Comentem suas opniões sobre usar ou não, na minha opnião template parser é uma das coisas que mais ajudam no desenvolvimento do front-end, o opencart atualmente não suporta template parser, a extensão .tpl que eles usam nos arquivos é apenas nomeclatura, mas o loader das views no final das contas da um require na view.tpl . Acho essencial o uso de um deles como o twig que é um dos componentes mantido pela Symfony, é muito facil de usar. Eu copiei e modifiquei algumas funções feitas em twig para opencart deste repositorio https://github.com/vanderson139/opencart-twig é muito útil, o tema fica mais limpo e facil de desenvolver, sem precisar ficar toda hora setando language, assets, links no $data da controller e passando para a view, assim a controller também fica mais limpa e transmite apenas os dados que importa.

qui é meio polêmico, seria legal desenvolver um mercado que gerencie todas extensões e temas grátis ou não, que foram desenvolvidas para o "novo opencart", porem pelo que eu li, segundo a licença do Opencart, ninguém alem deles podem criar mercado, posso estar enganado, a galera do https://arastta.org fizeram o deles, aparentemente já existe a um tempo significativo e ninguém encheu o saco.

Alguns deram ideia de usar bower e npm e Browsersync, que foi idéia do @vilsongabriel, fora isso também podemos usar uma library de minificação como o https://github.com/matthiasmullie/minify podemos jogar ele dentro do core, e ao executar o $this->document->addStyle() já sair minificado.

Um dos problemas gerais, não só no opencart, é como versionar alteração de banco de dados e como alterar o banco de forma segura e confiavel, é por isso que sempre usei sistemas de migrations, atualmente no opencart eu uso o https://phinx.org/ que é o mais estável da categoria. Quem tiver dúvida sobre o assunto acesse: https://en.wikipedia.org/wiki/Schema_migration

Definições para o painel do opencart

Comentem suas opniões sobre usar ou não o command line, e deem suas idéias de comandos novos que podemos criar. O command line facilita muito a minha vida, principalmente para deploy de projetos. Ele esta presentes nos principais framework, como Laravel, Symfony, Zend e entre outros.

Aqui meus amigos, esta um dos maiores diferenciais do "novo opencart". Criar as extensões em padrões modulares é a solução de muitos problemas, assim evitamos misturas de arquivos, conflitos e modificacoes no core, facilitando o gerenciamento da instalação e remoção de uma ou mais extensões, e entre outros benefícios.

Acho ridículo existir duas config.php semelhantes sem reaproveitamento nenhum, e também setar os caminhos absolutos, é por isso que consegui deixar tudo dinâmico e centralizar em um só lugar. Agora as configs são apenas para você adicionar ou editar coisas que vai usar em seu projeto, como conexão com o banco, etc, e ainda poder separar em ambientes diferentes sem precisar disponibilizar ou versionadas suas configs pessoais em projetos sendo desenvolvidos em equipe.

Eu gosto de rotular as coisas, para se acostumar já com os nomes e ficar mais fácil de identificar. Principalmente no nosso caso, como vamos usar algo existente, as vezes confundi a quem lê o que estamos mencionando naquele momento, se é o opencart novo ou o opencart atual, viu, me confundi :/

Atualmente estou usando o Eloquent ORM do Laravel para manipulação de models, é um componente do Laravel que pode ser usado em outras plataformas. Ele é bem simples de usar, semelhante ao Datamapper do Codeigniter. Se alguem não esta familiarizado com esta tecnologia confira nos links https://laravel.com/docs/5.1/eloquent e https://pt.wikipedia.org/wiki/Mapeamento_objeto-relacional a idéia aqui é aos poucos migrar as models nativas do opencart porque na minha opinião, acho ruim escrever sql puro e não obter muito reaproveitamento com isso. Comente o que acham, deem sugestões e opiniões.

A tradução será separada em três lugares:

• Dentro do core como de costume, mas sem sofrer alterações.
• Dentro da extensão, agora você pode adicionar suas traduções e também sobrepor traduções do core sem modifica-las diretamente.
• Dentro do tema. Acho essencial isso pois ao mesmo tempo que um front-end esta desenvolvendo o tema ele já pode desenvolvendo todo o translater sem mexer em controllers.

Uma coisa que eu gosto de usar, é uma função do Twig no theme que se chamada lang() nela você passa a palavra a ser buscada nos arquivos de tradução, sem precisar setar um monte de array na controller pra cada palavra a ser traduzida, exemplo de uso no html:

<p>{{ lang('empty_name', 'catalog/product') }}</p>

Vamos levar o OpenCart ao próximo nível, Segue exemplo:

https://opencart-api.com/product/opencart-restful-api-pro-v2-0/

Sei que provavelmente vamos pegar a última versão release do opencart e continuar a partir dela, porem estava pensando, caso possível, desenvolver uma forma que o core suporte qualquer versão, ou pelo menos boa parte das versões existentes, porque assim aquele desenvolvedor que já tem um projeto rolando e queira migrar para o "novo opencart", basta apenas informar para o composer qual versão ele esta desenvolvendo e modificar suas extensões e temaspara o novo padrão, em teoria iria rodar normalmente. Claro que é só uma idéia também, se der muito trabalho abandonaremos a mesma.

Talvez seja bom mudar o sistema de validação, atualmente o Opencart é feito meio que na mão a validação, pode até ser bom para o desempenho, mas crio que seria melhor usar uma boa Biblioteca para isso, substituindo aos poucos as validações nativas e até melhorando elas em alguns pontos para o padrão do Brasil se o foco for mais o Brasil ou deixar genérico mesmo.

Comentem suas opniões sobre se devemos usar ou não esta anomalia, sei que salvou as nossas vidas durante muito tempo e salva até hoje, mas se modularizarmos completamente as extensões e usamos events para modificar o core sem altera-lo aos poucos podemos não precisar mais deles.

Adoro o composer, acho que foi uma das coisas mais perfeita ja criada no mundo PHP. Uso ele para gerenciar e atualizar todo o projeto em qualquer ambiente, dev, test e production.
Existe um projeto do composer chamado Installers https://github.com/composer/installers, nele a galera adiciona "type" que servem para indicar o que deve ser feito com o pacote instalado que tiver especifico o mesmo "type". Deem uma olhada no repositório deles se tiverem dúvidas.
Atualmente criei um installers para gerenciar "core", "extensions" e "themes", assim cada um deles fica separado em repositórios, se eu quiser usar um determinado tema, eu simplesmente do um composer require nome-do-tema e ele automaticamente adiciona o tema na pasta themes/. O mesmo acontece com o core que é adicionado na pasta app/ e as extensões na pasta extensions/.

Desculpe ocultar algumas coisas, são dados da empresa onde trabalho.

Comentem suas opniões sobre como podemos melhorar e adicionar novas funcionalidades no core do Opencart. Como API, libraries que facilitam o desenvolvimento, melhorias no painel, etc.