This project is read-only.

Full source or compiled for customization/development

Topics: Customizing Orchard, Writing modules
May 3, 2012 at 3:23 PM

Hey guys, I am from small software house, and we just decided to replace our (a bit old) proprietary CMS with orchard. Now we try to figure out best practices for bringing it to live. So first question is obvious - every time we need to set up new project (new website for new client), what should be the process here?

I run into some sources discouraging from using compiled "encapsulated" version of orchard (, but didnt found any particular good reasons or pro-cons discussion about this matter.

The thing is - typical scenario will be, that we will use few standard modules (from gallery) and develop one or two custom, plus custom theme of course. Also, there are few senior developers (and probably they will not be the ones developing these small websites) and enough junior developers. So, first i would like to have orchard "closed" - because of possibility of nasty "hacks" to the core from junior developers (so that we can upgrade it later; be sure 3rd party modules will be compatible, reusability of modules, etc. etc.)

So, I think you know our motivation and concerns, lets have some nice discussion, why we really should or should not use full orchard sources for each and every little website :)

May 3, 2012 at 3:36 PM

If you want to prevent hacks to the Orchard source, you can set up your build process such that it downloads a fresh copy of the orchard source. This way there is no chance that hacks to orchard source can be deployed. You can still follow the dev process outlined in the SO post you linked. 

So far the only way I've developed has been to have the full Orchard source in my development project. I feel like it would suck to try to develop without it. 

May 3, 2012 at 5:39 PM

Orchard is *designed to be hacked* so if your primary objective is preventing hacking, maybe that's not the CMS for you. Maybe something closed source would be a better fit?

For me the #1 reason of working with full source is that updates are a 10 second deal most of the time..

May 3, 2012 at 5:59 PM

I would suggest to only work with Modules in your DVCS, and have every developer to use the public version of Orchard, and link to your private repos. They don't have permissions to commit to Orchard, so you are safe.

May 3, 2012 at 6:05 PM

I'd disagree with that. They won't be able to corrupt anybody else's clones, but they will be fully able to completely screw their own in a way that will be hard to recover unless they restart from scratch. But essentially, yes, it's pretty safe.

May 4, 2012 at 10:52 AM

Could you Bertrand and Sebastien please elaborate your method of source control? As far as I understand, when you work with a team on an Orchard site you clone the main Orchard repo and have all custom modules under version control separately.

  1. But how do you achieve that all devs use the same version of Orchard, updating it the same time?
  2. Where do you store the Media and App_Data folders?
  3. How is it achieved that a new developer just has to use right click - clone to get the whole workspace once? Or everybody clones all repos separately?

I'd be very interested in how this can be made simple to use.

May 4, 2012 at 4:04 PM

Maybe another approach could be to create a new repos, clone Orchard in this repos, and use it as the main repos for everyone, adding sub repos for your own modules.

May 4, 2012 at 4:13 PM

That's pretty much what we've done with Orchard Hungary. Advantage of this is simple cloning, Orchard, Media and also the SQL CE DB being in sync. Disadvantage is a slightly more complicated update (meaning one has to download the new source and overwrite the installation), but this is not a big deal and happens only a few times in a year.

May 4, 2012 at 5:19 PM

I never put the DB and Media under source control. Or at least not under the main repo.