... Or the guy who is just editing files directly on the server (or shovelling everything up with FTP), instead of sane version control.
(I'm not sure anyone doing the former can be counted as "Pro", WP or otherwise.)
... Or the guy who is just editing files directly on the server (or shovelling everything up with FTP), instead of sane version control.
(I'm not sure anyone doing the former can be counted as "Pro", WP or otherwise.)
(A) Database passwords are a security risk. You don't want them escaping to other servers when you clone or share code.
(B) Wordpress is commodity software. You are unlikely to need custom modifications to the source. "I'm on version 3.4.2" is sane enough version control.
(C) Database passwords are ephemeral. You don't need to keep a durable record of them. If your hard drive fails or you otherwise lose your record of them, you can just change the password. What is needed is a good backup strategy, not a durable password.
I would say live editing wp-config.php outside of version control is the best strategy, until you start needing to synchronize multiple webservers. At that point you should switch to some deployment and configuration manager like Chef or Puppet, not put passwords into version control.
(It seems I skipped actually writing something useful and went straight to durr version control, sorry.)
Points A) and C) are dead on. Addressing your point B), though:
Yes, it is commodity software. But most seem to use at least some plugins and themes, and making changes to those without a rollback is a nightmare. You can make backups before changing things, sure, but version control has that already built in.
(Sibling posts to yours point out that Wordpress looks in both the docroot and one level up for wp-config.php - if I ever manage a Wordpress site again I'll be sure to move it out.)