I know your method works flawlessly, but it scares the crap out of me.
Luckily Craft's update setup is magical.
What I do is this.
Make sure my repo is clear of unstaged files, just so the update can be in a commit all by itself.
Run the update on my local dev environment (with a local database) (Test)
Commit the updated files and push
Backup live ...
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 ...
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 actually keep all the craft system files gitignored. This way, all the assets are independent of the version of Craft and therefore of the updates. When it's time to run an update, I'll do it on dev first and then I'll run it in production knowing that it'll be fine.
So far I have not had a problem with this approach and it seems to me that it is a more ...
I personally use a slightly different method than what Jeremy recommends.
Clean repo on the git side of things: no unstaged or non committed files
Backup live DB and import in dev
Update dev (test)
Commit & deploy
Not encountered any problem so far and Craft runs its tests on both environments.
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 ...
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 ...
It looks like getenv returns a string (or false if the variable is not set, but it is in this case). So you need to cast the string to a boolean value to make it work. However, (bool)'false' gives true, not false. There are two possible solutions:
Set the variable to 0 instead of false in your .env file:
And then in your config:
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 ...
Alternatively, you could write your own yiic shell wrapper for each environment that defined CRAFT_ENVIRONMENT.
Something like yiicstaging:
Yes, if you set up proper multi environment configs, this isn't very hard. My config/general.php file usually look something like this:
'*' => array(
// some general settings here
'mydomain.craft.dev' => array(
'environment' => 'local',
'devMode' => true,
'useCompressedJs' => false,
The environment-specific array that Craft uses is determined by the $_SERVER['SERVER_NAME'] variable (usuall your domain name), not the database hostname. Instead of using localhost to trigger the env-specific settings, you should use your domain. Your db.php should looks more like this:
'*' => array(
'server' => '...
Another option is to use named environments instead of using domain matching.
in your index.php file, just set (changing 'development' to whatever you like):
Then your environmental config array can use "development" as a key, instead of localhost or .dev
When you are accessing a database "from a distance", it won't be called "localhost". Having the port in there is probably helpful, but you'll want to specify the DB server by its IP address.
'localhost' => array(
'server' => '(DB IP address):3307'
Also, be sure that your server database is allowing remote access. By default, most DBs will only ...
If you're using MAMP you might also want to try using ".dev" or ".dv" for your array like so in your general.php config file:
'.dev' => array(
'devMode' => true,
Versus using localhost.
UPDATED Local / Live General.php file setup:
'*' => array(
'cpTrigger' => 'admin',
'omitScriptNameInUrls' => true,...
This issue may be that your database name, prefix, password, etc are different on your local machine, than the ArcusTech server. If your local values don't match the values in the block defined with the asterisk, you won't be able to connect.
Most local databases with tools like MAMP, use a default user and password like 'root'. Try to look into some of ...
Well, I can't really mark any of these as the answer, and I have no clue what actually did it, the config simply started working. I restarted all services and my machine many times during this process, so it was nothing quite so simple. I guess this is what I get for developing on a Windows machine. I considered deleting the question, but there's some ...
For anyone who is interested - I did a quick mashup of the Craft and Laravel Homestead documentation to outline the process I went through for setting up my first Craft site locally on a Vagrant/Homestead box.
Thanks to the guys over at Straight Up Craft for the video about Vagrant and Craft which introduced me to Homestead
That’s a good thing - you definitely don’t want to allow direct HTTP traffic to your craft/ folder, as people would be able to access your config settings, license key, and plenty of other sensitive data.
There’s a .htaccess file inside your craft/ folder with Deny from all in it, which is what is responsible for that 403 error you’re getting. Keep it in ...
I've been using Laravel Homestead for local dev (and Forge controlled VPS' for staging). Both have been hugely successful for me – I've not touched MAMP for months.
Craft works off-the-shelf with both.
Looks like the .htaccess file included with Craft is not being read or you didn't rename it (should be .htaccess with the period at the beginning).
That's why /index.php/admin is working but /admin/ is not.
One other possibility is Apache is setup to ignore .htaccess files. If that's the case, add this to your httpd-vhosts.conf file.
The default MAMP DB credentials are indeed root:root, as you have already, so you should check that you did indeed create a database (set up as detailed here) and that it is indeed called ‘mycraft’.
Also check in your MAMP control panel that the MySQL is actually running:
I just use the included IIS on Windows 10 for development. Install MySQL and PHP and all runs fairly smoothly.
Just recently recently configured this on a new Win10 machine and made a note of another couple of points:
Make sure that IIS_IUSRs has full permission to: c:\Windows\Temp and the directory where you will hold your development websites.
After up ...
Performance? Doubtful there is a significant difference, compared to the cost of, say, a database query. It all boils down to accessing arrays, and the number of function calls or string manipulations that it takes to get there is probably not worth worrying about.
The way I see it is that ENV vars are for configuration, and aliases are for convenience / ...