Closed royduin closed 8 years ago
Totally agree. I've been just starting with October CMS and I setup a gitignore to not track /vendor folders in the repo. This excluded the vendor folders in the theme (correctly) but then other team members could not replicate the install by running 'composer install'. I needed to check in the vendor/ folder for the theme for them to even get the pages to load. If this was all managed by the top-level composer file, and the themes referenced the top-level vendor/ folder it would make things much easier on dev teams that need to bring new members up to speed quickly.
@daftspunk or @alekseybobkov, what do you guys think of this?
:+1:
This would make the dependency management for OctoberCMS much smoother. All dependencies of the framework including libraries, themes and plug-ins would be easily managed with this suggested setup.
Running composer require october/october
should do the trick, but I am getting an error. Perhaps because no version has been added? (#2256)
All RainLab plugins have been added to composer just recently, October itself has always been "composerized", the project is set up with this command:
composer create-project october/october myoctober dev-master
Is there anything we are missing?
@daftspunk, @pedzed misunderstood the usage of october/october package, he thinks it should be usable as a requirement for his project, and not as a template as in your snippet. see the discussion on the slack channel.
Thanks @cdarken
This issue may be of some interest to all: #2119
We would really love to document this (how to integrate October with an existing Laravel app) but it requires feedback and confirmation that it actually works ;-)
TL;DR to add October as a composer package, don't add october/october
, add the OctoberCMS packages instead:
"october/rain": "~1.0",
"october/system": "~1.0",
"october/backend": "~1.0",
"october/cms": "~1.0",
Very nice I can install OctoberCMS with Composer but what about plugins and themes? Composer installers does already have support build-in for OctoberCMS, see: https://github.com/composer/installers. And what about OctoberCMS as a dependency too? See also: http://octobercms.com/forum/post/octobercms-itself-as-dependency
If you ask me; if I start a project I should have just some structure like this:
.gitignore
to ignore thevendor/
directory and the.env
file.env
with all environment specific variables.env.example
a example file with all possible variables explainedcomposer.json
where I declare all my dependencies, including OctoberCMS, all plugins, themes and maybe translations tooweb/index.php
just a reference to bootstrap OctoberCMSweb/.htaccess
my own rules including a rewrite for OctoberCMSvendor/*
where all Composer packages comeThis way updating is easy and in my control. I don't like updates and installations of plugins through the backend that much. And why should I've things in my repository which are already in another repository?
Assets of plugins and themes which need to be accessible externally should automatically come somewhere in the
web/
directory (this could be handled with for example a global Gulp or Grunt setup?). The vhost should point to that directory for the best security. And for any customization I'd like to have some fallback system so I can have aplugins/
andthemes/
directory in my root which are loaded but my plugins and themes installed through Composer too. Or combine it and put everything in theweb/
directory like for example https://github.com/gwa/bedrock-multisite-skeleton. That's something similar as I describe for Wordpress.For paid themes and plugins it would be nice if those get a private GIT repo and when I've bought something I get access to it and I can install them with Composer too.
What do you guys think of this?