My general approach for this, not just with Craft, but with all CMSes is to have a shared database for development. It's not the most ideal solution, since there can be overwriting of work, but it at least prevents schema changes from having to be redone across multiple environments.
Once a site goes live, maintaining a dev environment alongside live ...
The trouble is, there's no one way to utilize AWS. You can set up a simple VPS, or get endlessly complicated with load-balancing multiple servers, adding CDN, utilizing cool caching options, and plenty more.
I've been fortunate enough to learn a lot from a siteops team that established all the infrastructure. It's a bit much for getting started, but the ...
Hmm. I started out having a feeling existing tools might be a best approach here. I soon found that even with the better of these, except for in-dev patching, we may want to wait for a Craft capability for transferring any less than a full dump of data in a Craft database. Syncing databases is a tricky problem, unless they are of exactly the same structural ...
I'm running Amazon S3+CloudFront on several of my sites. There's not really much to it, Craft makes it really easy:
Create a new Amazon S3 assets source in Craft.
Set up CloudFront in AWS (see this link).
In the settings for your assets source, add your cloudfront url (something like http://xxxxxxxxx.cloudfront.net/, or your custom CNAME if you set one up) ...
Update for Craft 3
Craft 3 includes native support for multi-site installation. Here's a link to the official docs and here's a link to another question with more resources.
Old answer for Craft 1 & 2
Credit to @LukeHolder for the original answer, but here's a bit more detailed and technical answer. Note, this might not be possible on all hosts.
Note: This method is not for the faint of heart and might not be for everybody, but can be useful in some situations.
One thing we do (at Airtype Studio, where I work) for larger installations is set up a couple of load-balanced pools of servers: an app tier and a web tier. In fact, the environment architecture is very similar to this:
This type of ...
Yes, it is possible to have a Craft install on multiple domains and subdomains as long as you only access the control panel from a single domain and you only have a single installation of craft that all the domains and subdomains use.
The limitation is all domains would be using the same url router and content - although for multi language content having ...
I work with git for all my projects, I had to spend some time figuring out how to set up the folders and files, i.e.: what to gitignore. But it now works pretty well. All the core files are independent from the configuration/assets so it's pretty easy to work with once it's been setup.
Now, in regards to the database, I have been working with separate, ...
We currently handle this with database dumps from dev and taking screenshots of config screens and attaching them to git pull requests. There needs to be a better way though.
The only CMS that has any kind of solution that I know of to this problem is Wordpress with this plugin https://deliciousbrains.com/wp-migrate-db-pro/
I found a great blog post where the author uses Phinx and MySQL Query Log to create database migrations. I summarized its content into 10 easy steps:
Enable the MySQL Query Log on your dev environment by editing your mysql my.cnf file.
Set the general_log key to 1 and general_log_file to /var/log/mysql/mysql.log
Take a snapshot of your ...
Essentially the question is "how can I manage changing database content across environments" which has been covered several times here before. Some leisure reading:
What's the best practice for handling data migration and organization across development environments?
Git Workflow and Multi Environment - how to approach
What's the best practice ...
This morning a couple of postings on Craft Slack #devops area linked good descriptions of basic server security, led by @merlingore there.
Their instructions are tilted towards Ubuntu as far as specifics, but should fit for any Linux VPS.
Recording the links here so we don't lose the patterns. I agree with them because they're actually the same as what I ...
I guess it depends. So, behind the scenes, Craft can have different cache drivers. You might use the db or file cache, or something like Redis or Memcache.
Took a peek at ClearCachesTool, and it looks like it's doing the things you mentioned:
I absolutely agree with "build locally and then upload it".
Deploybot can deploy with ftp, and makes it quite painless to keep local and remote and git repo all in sync.
I make debugging sorts of changes directly on the server (tweak the config, tweak .htaccess, that sort of thing), but any change I want to keep I make sure to get into git.
Something I wish I knew a long time ago, as it has bitten us quite a few times already in the past. Nothing as bad as having an automated deployment process that fails once in a while.
I'm sharing it here, but I believe it would be good to add it to the knowledge base too (https://craftcms.com/knowledge-base/deployment-best-practices)
The solution is to ...
In my humble opinion, this is a task for Grunt / Gulp, not for Craft.
Addy Osmani has an excellent article on Environment-specific builds that would be interesting for you and the kind of use case you mention.
In short, gulp-replace or gulp-processhtml and gulp-preprocess will give you what you need to build such functionality in your build scripts. ...
I would suggest to read through the following articles:
About reinstalling craft on your droplet and uploading the local database:
the craft install i used in my local dev environment will be pushed ...
The error that you are seeing is because you have changes in your local repo that need to be saved (committed) first.
I'm also a huge Git user and wanted to touch on a few items in your question.
The craft/app folder should always be in your Git repository as its the foundation of making your site run Craft.
If you want to see an example Craft Git project, ...
Normally folders in the /craft/storage/runtime/* directory are just cached files.
Those files are generated by craft, so really they're generated by php/php-fpm/nginx/apache or what ever you've got setup.
Maybe check the user that made those folders are in the www-data group if you do want to look into it further.
The better solution is to completely ...
You can have your templates folder outside the Craft folder. Just define a CRAFT_TEMPLATES_PATH variable in your index.php and tell Craft where your folder is located:
// Move templates path to right above web root
define('CRAFT_TEMPLATES_PATH', realpath(dirname(__FILE__) . "/../templates").'/');
I learned about this in @Jake Chapman's CraftCMS-...
The best way to go is build it locally then upload it.
After the initial upload, if you use a smart FTP client like Transmit you can sync both version to update your local version before making local changes then re-sync to upload them.
Editing online can be done but for me it is crucial that you always have a local backup just in case something happens, ...
So the way I'd recommend doing it is that you use .gitignore to exclude your /vendor directory from the repo; a good starter .gitignore file can be found here: https://github.com/nystudio107/craft-scripts/blob/master/example.gitignore
Then you'll work on it in local dev, update Craft/plugins in local dev, and on deploy to production have it do composer ...
I'm currently implementing a workflow that's very efficient for us.
The trick is to use Backup Pro to "backup" locally and then "restore" once the site is deployed. This essentially version controls the DB without lots of manual DB dropping and importing. Communication is very important with this method as Devs and Stakeholders need to be aware of how the ...
My dilemma is that for the DB updates to run for Craft, I have to hit visit the control panel and initiate them.
Currently true, but only if a new database migration has been introduced during the update. Otherwise, it should be seemless.
I need a programmatic solution so that I can ping a URL after the deployment is finished, and initiate the DB ...
At step 5 you basically start working with another person. Their content input is just as important as your code changes.
Therefore you'll need to alter the workflow as
Code flowing in "Local > Staging > Production" direction
Database flowing in "Local < Staging < Production" direction
At the risk of offering a "link answer", the Setting up a New Craft CMS 3 Project has a section on DEPLOYING CRAFT CMS that should be useful to you.
I've never heard of Rocketeer, but popular ways to handle deployments are via buddy.works, Laravel Forge and the like. We talk a lot about this on the Website Deployment without Tears episode of devMode.fm
In light of RitterKnight's answer, perhaps you deserve a real answer to your question... You asked "where can I learn", and I said "don't try this at home".
"If you're just screwing around, though, there's no better way than to jump right in and start learning."
If the stakes are low, go ahead and give it a shot... We've all been ...
If you've never built a site with a database before, I'd caution against going straight to DigitalOcean & ServerPilot. Those services are designed for people who have several years worth of experience dealing with:
Apache and/or Nginx
Separate email management
It's like saying, "I've never driven a car ...
I was being silly here. We have separate folder for all frontend assets (including twig templates), which will be copied over to the craft folder on build. The target files are gitignored and need to be force add to git. I added the files under web but missed out on the craft/templates folder.