SilverStripe 4
Is it possible to Install modules without Composer?
You could try, but I wouldn’t recommend it. Some modules without dependencies could just be downloaded (or git cloned) in to your project root and they might work as expected. Many others will have dependencies that will also need to be installed, and those dependencies may in turn have other dependencies. Composer installs all those dependencies for you automatically and makes it easy to keep them up to date with new versions and patches.
1 Like
Is it still okay to install modules locally with Composer and then upload everything to a server that doesn’t support Composer (specifically for Silverstripe 4?).
That’s how I used to do it for SS3.
1 Like
Absolutely. That’s how I work. I don’t like having composer on production servers. The only thing to be careful about is that (depending on your dev system) symlinks are sometimes used when assets are exposed (css, js, etc.) via composer.
You need to be sure that whatever method you’re using to transfer the files to production maintains these exposed assets.
You can set the mode which composer uses to expose assets a couple of ways, the one I tend to use is by adding SS_VENDOR_METHOD=copy to the .env file for the project. This will make sure that files are actually copied rather than symlinked during the expose process.
2 Likes
Thanks for the reply! I noticed the expose mode setting could be copy instead of symlinks.
I do really like the new directory organisation of SS4. It’s a great idea.
I’m struggling to get the simplest of SS3 sites to convert to SS4 though. The upgrade-code recompose stage of the upgrade-code all keeps claiming that a composer lock file is out of date and needs a composer update but running composer update says everything is fully up to date. I deleted the lock file and it recreated it and said it was out of date again. Need to try again.
Right! I’ve finally nailed my first full upgrade from SS3 to SS4! What a job. I’m fully on board with the latest app/src and public setup. No compromises.
The only feature I’ve temporarily disabled is Grid Field drag and drop sorting. I believe there is an update but I’ve got it working enough to actually try pushing it all to a live sub domain server.
I think the most difficult thing is referencing your namespaced classes for GridFields and ModelAdmin. I couldn’t get the old pop-up in-cms-page editor working so added a ModelAdmin.
And the other gotcha is where the Templates for namespaced Classes end up living and then where the ones you might have modified for the standard Login or Form sections then live as well. Old templates with $ThemeDir also break. Then includes need the namespace reference as well or end up living in a different Includes directory. Once that was all fathomed it was all gravy.
Oh and the big one is splitting up Controllers into separate files. That’s a very big job.
I managed to get my CustomSiteConfig up and running. I got my isLiveMode function working as well.
The other issue I had was with my app namespace needing adding to Database Classes as well. Some Draft mode data had also been wiped during the upgrade. Copying it from _Live to the draft brought it back into the CMS though - manually.
In the end the only functionality I lost was related to the GridField and that’s just because I’m totally fed up of reading documentation today so I’ll try again another day!
I’m pretty chuffed with myself. That was the most difficult SilverStripe related update ever by a long way and I’ve been with SS since version 2 came out.
SilverStripe 4 as an app is very resilient. It took being broken in it’s stride. Error messages seem to be much improved. At least you can throw multiple attempts at it until it works and it doesn’t break everything. It’s robust.
Still… that was a real challenge. I was really annoyed by how many times I’d failed to do the SS4 upgrade so far and I was determined to sort it.
1 Like
@Tim - I like the idea of having a “build” machine and a production machine. Thanks for the advice.
It’s certainly the way to go in my opinion. Like a lot of developers, I do all development work locally* (where composer manages the code) and then push it to production servers. One thing to be careful of is that your environments match, so if the production server is running PHP7.0 and MySQL 5.5, then your local environment should be as well. That way you are much less likely to hit compatibility issues.
*in my case, “locally” means on a virtual machine running in a Docker container that matches the target environment
Isn’t that in the face of comments here: What to .gitignore in SS 4.2+ ?
I know I’m the odd one out but I really don’t like Composer. Feels like you just never know what you’ve got as this dependancy calls this one, and this calls that and etc etc…
Like you, I have a Docker container locally and two remotes I push to. In the past I’ve used GIT branches to manage my projects and CMS Vendor code. I’d have a repo for “myVersion” of the CMS that had a remote to the Vendors code. Each project repo has a remote branch to “myVersion”. In that way I could make changes to the core and/or have specific settings I want for all projects I run.
I was surprised to see the recommendation is to ignore the vendor directory and run composer on the remotes.
I installed the TagField module manually and it pretty much worked. Needed to shift some public assets around, assume missing symlinks and I manually added i to autoload. Can see how not using Composer could make life a misery with a large module.
It comes down to personal opinions, workflows, etc.
As I said, I don’t run composer on my production machines as a rule, but I wouldn’t want to actually build the site without using it these days.