What development server settings need changing (DB or code)?

Question

I have a script that downloads a copy of the production database and imports it to my development machine. I also rsync the production code to a staging server every so often. There are certain files that I'm ignoring, and a few changes I always have to make to local database. A few of the things I would like to achieve on my development machine are:

1. Use the development database
2. Never email customers
3. Never charge credit cards
4. All urls should be local
5. Turn off caching
6. Turn off Google Analytics
7. Turn on demo store notice
8. Enable DEVELOPER_MODE

Please feel free to add more that make sense.

Answer 1

The files I don't update:

• app/etc/local.xml (1)
• .htaccess (8)

The SQL script that I've started:

-- LOCAL DATABASE CHANGES

-- Don't send emails (2)
UPDATE core_config_data
  SET value = 0
  WHERE path LIKE "sales_email/%/enabled";

-- Send emails to [email protected] (2)
UPDATE core_config_data
  SET value = "[email protected]"
  WHERE value LIKE "%@example.com"
    AND (path LIKE "contacts/%"
      OR path LIKE "sales_email/%");

-- Set Authorize.net to test mode (3)
UPDATE core_config_data
  SET value = 1
  WHERE path LIKE 'payment/authorizenet/test';

-- Update store URLs (4)
UPDATE core_config_data
SET value = REPLACE(value, "www.example.com", "www.example.local"),
  value = REPLACE(value, "admin.example.com", "admin.example.local"),
  value = REPLACE(value, "assets.example.com", "assets.example.local")
WHERE value LIKE "%.example.com%";

-- Disable caching (5)
UPDATE core_cache_option
  SET value = 0
  WHERE value = 1;

-- Turn off GA (6)
UPDATE core_config_data
  SET value = 0
  WHERE path = "google/analytics/active";

-- Turn on Demo store notice (7)
UPDATE core_config_data
  SET value = 1
  WHERE path = "design/head/demonotice";

-- Replace logo with demo logo (7)
UPDATE core_config_data
  SET value = REPLACE(value, 'mystore-logo.png', 'mystore-demo-logo.png')
  WHERE value LIKE "%mystore-logo.png%";

Answer 2

Just to add to Theodores' answer, version control with a CMS as large as Magento can be one of the most helpful things in the world. Tracking changes, taking steps back, and grouping your projects are all big time savers - and only a few of the benefits of using a tool like git!

Here is a good list of queries to clear all customer and order data, which I highly recommend you do for any development database: http://www.magentocommerce.com/wiki/import-export_and_data_manipulation/deleting_order_and_customer_data_with_sql

I recommend running and logging your MySQL script via Magento's core_write function like so:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
require_once('../magento/app/Mage.php');

Mage::app();

$write = Mage::getSingleton('core/resource')->getConnection('core_write');

$write->query(" INSERT INTO table_name (`whatever`, `columns`, `required`)
VALUES  ( 'corresponding', 'db', 'values')" );

?>

note: the above code assumes you're running yourscript.php in a directory one level above your Magento root folder

One of the most difficult things in working with Magento (I've found) is version controlling its complex database.

Each little adminhtml change queries the database, changing any number of rows and tables.

There are (some) tools out there that can assist you in version controlling databases (check out google for more info), but a simple starting place to see differences between a clean DB of the same Magento version, your production, staging, and or development databases (or any combination thereof) is to simply perform a database dump of the two you'd like to compare and diffing the two dump.sql files:

mysqldump --skip-comments --skip-extended-insert -u root -p dbName1>file1.sql
mysqldump --skip-comments --skip-extended-insert -u root -p dbName2>file2.sql
diff file1.sql file2.sql > diff.txt

note: the output of a database diff can be far too verbose in some more customized situations. I've created .txt diff files before that were over 6 million lines long :(

What development environment are you going to be using? MAMP? LAMP? Ensuring you never email customers is fairly easy, when developing on a localhost site you can control your sendmail settings via the php runtime environment (your first development environment should always be a localhost env. i.m.o.)

URL structure should be coded into the site by using Magento's MVC and Magento/PHP best practice to dynamically call urls i.e.

{{media url="path/to/image.jpg"}}

note: the above would pull image.jpg located at magento/media/path/to/image.jpg

Answer 3

You wrote "Never charge credit card" but I think it is more, so turn your payment provider to be in TESTMODE.

Answer 4

Sanitise email addresses (2):

-- email address sanitisation
UPDATE customer_entity SET email = CONCAT('sanitized+', entity_id, '@example.com');
-- for excluding your own, just add
-- WHERE email NOT LIKE ('[email protected]');

UPDATE sales_flat_order sfo JOIN customer_entity ce SET sfo.customer_email = ce.email WHERE sfo.customer_id = ce.entity_id;
UPDATE sales_flat_quote sfo JOIN customer_entity ce SET sfo.customer_email = ce.email WHERE sfo.customer_id = ce.entity_id;
UPDATE sales_flat_order_address sfo JOIN customer_entity ce SET sfo.email = ce.email WHERE sfo.customer_id = ce.entity_id;

Update your payment gateways to use their test/staging/sandbox enviro details - this should be a core_config update (3)

Turn logging on for the dev enviro's (8)

UPDATE `core_config_data` SET `value` = 1 where path = 'dev/log/active';

If you make use of a custom admin URL on your live server e.g. http://myadmin.mysite.com you can restore the non custom admin URL with the following update (i.e. http://dev.local/admin) (9)

UPDATE `core_config_data` SET `value` = 0 where `path` = 'admin/url/use_custom';
DELETE FROM `core_config_data` WHERE `path` = 'admin/url/custom';

If you make use of solr or some other search engine you may want to set it to use your sandbox search engine or mysql full text if you do not have a search engine sandbox (this update is for enterprise, I'm not sure about community). (10)

UPDATE `core_config_data` SET `value` = 'catalogsearch/fulltext_engine' WHERE path = 'catalog/search/engine';

Answer 5

You should use version control, i.e. git, to deploy your master code to your production, staging and development environments. In that way you can use some of the niceties of the version control way of doing things such as ignoring the htaccess and local.xml files. Various .gitignore for Magento files exist on the internet.

You can also use a much smaller database if you are able to do your local work on a database cleared of customer data and previous sales orders. Doing so means that you do not have to worry about accidentally mass emailing the customers.

For developer mode you can also have a different index.php. Create a tar archive of index.php, htacess and local.xml and save it as 'local_magento.tar' and then put together a shell script such as rebuild.sh that does things like:

mv magento magento-old
git clone https://yourrepo.com/yourproject/magento.git
tar xvf local_magento.tar
chmod -R ugoa+rw magento/var
rm magento/var/log/system.log

You can keep the media folders pointing to the live site and out of version control. In that way you have a small amount to sync.

If you don't want to start from 'fresh' you can just pull the repository again, syncing you code in seconds, no rsync needed.

IMHO version control is key to what you want to achieve here, plus some of the mysql scripts mentioned in other answers to your question.