I have an app built on laravel and am using Bitbucket to manage versioning. Currently I'm running multiple sites from this one code base/branch. I'm wanting to have the ability to change the colors for each site as well as add some custom code for some of the pages. There are core parts of the site that will never change unless all the sites need to be updated. What is the best way to set this up in Bitbucket so that if I need to make an update to the core code and push it to all the sites while having the ability to customize certain portions of each site?
I’m in a similar boat and I solved this by creating a new value in the .env file: APP_BRANDING, which is different for each site. In the config/app.php file I have a line like this:
'branding'=> env('APP_BRANDING', 'default');
Then I can check what the value of config('app.branding') is in the code, and (for example) change the footer based off its value.
You don’t need to have just one value for this. It may make more sense for you to have multiple depending on what changes between sites.
You shouldn’t be saving the .env to your version control, so you shouldn’t need to do anything different for deployment.
This is the approach I did with a similar project. It's especially useful, if the amount of customization's is rather huge and includes many files.
I have a folder structure like this (not all actual files and folders are listed here, just important ones):
core/
.git
app/
config/
database/
public -> ../design/public/
resources -> ../design/resources/
routes/
.gitignore
design/
.git
public/
resources/
.gitignore
So I have two main folders core and design. The core folder has symlinks to public and resources located in the design folder. Both folders have their own git repository. You don't even need to exclude public and resources in the .gitignore of the core folder, because git will just keep track of the symlinks not their content.
Of course you can also move single files like special controllers, configs, database seeds, etc. to the design folder as well, if they're not part of the core components of your app.
On your server(s) you deploy the app in the same folder structure. You pull one repository in the core folder and the other in the design folder. You can freely work on the core repository and push the updates to all servers. And if you have design updates for sites you can work on the design repository and push that to a certain site.
Hope you could follow my explanation - for me this scenario works pretty well!
Related
UPDATE: I missed a layer in the directory structure (the laravel parent folder, specifically). I'm quite embarassed...
I have a Mercurial repository tracking a Laravel project I've built under
IIS 6, with the following directory structure:
inetpub
|--laravel
|--app
|--bootstrap
|--vendor
|--wwwroot
|--Project
|--OtherScript (set to ignore in .hgignore)
I now want to begin work on a second project, and have modified the directory structure accordingly:
inetpub
|--laravel
|--app
|--app2
|--bootstrap
|--bootstrap2
|--vendor
|--wwwroot
|--Project
|--Project2
|--OtherScript (set to ignore in .hgignore)
I've added the "2" folders to the .hgignore for the original repository, but I'm having trouble working out how to set up a separate repository that ignores the original project folders, and will just track the 2s. I thought I could just create a new repository covering inetpub that uses a different .hgignore file, but when I create the repository it automatically references the .hgignore file established for the first repository. I'm presumably missing something, but I'm not sure what. How can I make this work? The project is just starting, so restructuring is entirely viable if that's necessary.
Two repositories residing in the same directory does not work.
There are several options which might suit your needs, though:
a) Use a parent directory in which you organize your projects in sub-directories. This is usually the recommended the standard approach with mercurial; each of the sub-direcoties becomes an independent repository. The parent directory would not contain much, but can be made a separate repository as well, if desired.
b) Use branches for different projects. Switching between projects then requires switching branches in your project.
c) You can extend option (a) and consider using sub-repositories or guest repositories. They come with some rough edges, thus their use will need careful consideration. You can also start with option (a) and convert it to option (c) at any later time. See Subrepository and also the links in the 'Alternatives' section.
As an aid to others fumbling their way to a better understanding of doing this with Sourcetree, here's a quick overview of what I've done based on planetmaker's advice.
Used the "Clone/New" option to created individual new repositories from the app, bootstrap and Project folders (I've determined that there's no point in tracking vendor).
Committed the contents of each of those repositories.
Created a new Project_Repository folder outside of inetpub
Created a new Repository from the Project_Repository folder
With the Project_Repository tab open, selected "Add Subdirectory" from the Repository menu, and selected the app directory.
Repeat 4. for bootstrap and Project
After doing that, I have a current copy of the content of all 3 directories in the Project_Repository folder, along with the appropriate .hg files. I'm optimistic that this will work well for Project2 as well.
If i've built a web app using code igniter, what's the proper way to deploy it? Should my install only include my files, or do I also package all the codeigniter code with it?
I'm just entering into the world of open source so I'm not so sure what protocol is.
Thanks.
This is a good question and I've seen it done both ways. There's definitely reasons Not to include the CI files. Like any potential in the future license changes. And it seems like with the projects that are shared by more experienced developers that is how they do it.
Because if you are sharing your project for other CI developers, then the reality is they will not use the copy of CI you include - they will fold your files into their version of CI. So including JUST the files needed for your app - actually makes much it easier. Its certainly what I would prefer. Just keep the standard application folder structure: config controllers models etc. but only include the folders that you have files for. And make it clear what version of CI you have tested it on. If you can say it will work on the release version (not the beta) then people on PHP 5.2 will know they can use it.
Of course you need to include all the CodeIgniter files, or else how would it run?
Most people tend to rename the application and system files and place them outside of the web root for security reasons. "After moving them, open your main index.php file and set the $system_folder and $application_folder variables, preferably with a full path, e.g. '/www/MyUser/system'".
I'm looking for a simple tool that would allow users to update and tag assets.
THen search/browse for assets and view the assets in the search results.
I have lots of files, i.e. logos, buttons, infographics, icons. I'd like to be able to share the with co-workers and have them be able to easily locate them without have to guess based on file names.
Right now I'm using apache with dir listing and htaccess. But this is less than ideal.
Are you talking about Version Controls? If so, Git can help.
Is there a recommended location to store static resources (images, css, js, etc) in a DotNetNuke 5.x installation?
There are /images and /js folders as well as a /Resources folder that contains resources. There appears to be some overlap as MicrosoftAjax.js is in multiple locations (but might be different versions?). I also could put resources in a /DesktopModule/ModuleX location.
Does anyone know if there is a difference in using any of these folders?
I kinda like the idea of all static resources being under a common folder (/Resources) so I could set caching rule headers, permissions, etc on them in one place.
Has anyone used a separate image server to serve DotNetNuke static content?
Pros and Cons of a separate image server (e.g. images.mydomain.com)?
If you own the entire DNN installation, then it can certainly make sense to consolidate all of your resources into one place (whether its the Resources folder used by DNN, or a different folder that DNN doesn't know about). If you're developing a module that will be installed onto a site that you don't totally own, then the considerate thing to do is to constrain your resources within the DesktopModules folder for your module.
Some things to consider with regards to DNN folders:
If you have content under a module's folder, uninstalling that module will give you the option to delete that content. This can help you keep things clean and organized, or it can make it can be dangerous if you have multiple module definitions sharing the same files... (Even more dangerous can be the uninstall SQL scripts; make sure you don't accidentally uninstall a module which has an uninstall script attached)
You can use the DNN file manager to upload/delete/rename files within the Portals directory, so it may make sense to put files there if site administrators should have control of them
Putting content outside of the module's folder will make it slightly more difficult to link to (especially if it's on a portal specific folder, i.e. you have to ask the PortalSettings object for the path every time)
It's uncommon to keep resources outside of the module's folder, and so may cause confusion if you bring an experienced DNN developer into the project
For skins and containers, you can use their own folders under the Portals directory. As bdukes said, this way site administrators can control them within DNN.
For modules, I have used the module's folder and module.css for defaults that can be overridden by skin or container css. This works because skin and container css are loaded after the module.css.
It is possible to have extra .Net "special" folders (App_Code, App_Themes, etc.) inside of a subdirectory, rather than in the root?
I am integrating with a CMS that dumps an enormous amount of stuff in the root. I would like to keep all my stuff in a single subfolder, as this will greatly ease my SVN and deployment burden. As it sits, I have to pick through all the stuff to figure out what's mine and what's theirs, selectively committing and ignoring -- it takes about an hour.
I can sure put all my Web forms in a folder. But I have classes in the App_Code and images and stylesheets in App_Themes that I need to deal with.
So, is there anyway to have an additional App_Code and App_Themes in a subdirectory, or are these limited to the root only?
(And, yes, I know about creating an Appication, but this won't work. I need to run in the same context as everything in the root of the site, so it's not really a separate, conceptual application.)
No, you can only have one App_Code folder per ASP.NET application.