Initialize Git repo on wp-content

[stefanoverna]

I think it's a better practice to make a git repo inside the wp-content directory. Wordpress is just a "library" that you can update without changes is the "application" code.

[etienne]

How do you deploy WordPress updates, though? My workflow has been to include everything under version control and never touch the server manually. Maybe I can include options to control this behavior, or just don't initialize the git repo. I've been debating whether this is the job of the gem.

[emzo]

Yes, I include everything under version control as well. I deploy using Capistrano and never touch the production server manually. Whenever I can, I try to include "libraries" (WordPress itself, plugins etc.) as git submodules. My directory structure looks something like this:

my_project
├── Capfile
├── config
│  ├── deploy.rb
│  └── nginx.conf
└── public
   ├── index.php
   ├── wp-config.php
   ├── wp-content
   │   ├── plugins
   │   │   └── wordless (submodule)
   │   ├── themes
   │   │   └── my_theme
   │   └── uploads
   └── wordpress (submodule)

I think @etienne is right in that this should be left up to the developer, and maybe the Wordless gem should just not bother initialising a git repo at all. It's easy enough for the developer to just git init . wherever he/she wants to, be that the top-level project directory, or only the wordless theme.

[etienne]

@emzo: I'm curious about your setup. It look too good to be true. How do you have WordPress itself in a sub-directory of your public directory? I thought the WordPress installation needed to be at the root level of the public directory.

Also, it's good that you mention git submodules because I've been debating using that for the Wordless plugin. In fact, in previous versions of the gem I installed the plugin as a submodule, and I later changed that to a plain git repo, after reading things like this. The plain git repo seemed like a much simpler alternative, so I'm curious to hear about the pro's of actual submodules.

[emzo]

Have a look at http://codex.wordpress.org/Giving_WordPress_Its_Own_Directory Basically, these are the steps I follow:

1. Copy public/wordpress/index.php to public/index.php
2. In public/index.php
   • change require('./wp-blog-header.php');
   • to require('./wordpress/wp-blog-header.php');
3. In public/wp-config.php set the following:
   • define('WP_SITEURL', 'http://example.com/wordpress');
   • define('WP_HOME', 'http://example.com');
4. In my web server config, I set the web root to be my_project/public

WordPress will automatically look for a wp-config.php file one level up from the WordPress application directory, so I can easily upgrade WordPress without clobbering my config.

As for git submodules, I'm still not 100% sure it's the best way to do things, but it's not as bad as people think. I just git submodule add git://github.com/markjaquith/WordPress.git public/wordpress, and just update it to the latest tag when a new version comes out. This stackoverflow question helped me quite a bit.

[etienne]

I can't believe I didn't know this. Thanks, that's very useful.

It dawns on me that many people will want many different ways to set up WordPress and Wordless.

1. Some people want WordPress at the root level, some people want it in its own directory.
2. Some want a Git repo at the root level, some people want it in wp-content, and presumably some people don't want version control at all (or want to use some other VCS).
3. Some want the Wordless plugin installed as a git submodule, some as a regular git repo, and some don't want it under version control.

That's a lot of possibilities. I could offer command line options for all of those, but it could easily lead to unsightly commands like this:

wordless new mysite --locale=fr_FR --wp=root --git-style=root --plugin=submodule

One possibility would be to make the gem interactive, wizard-style. It would ask you questions along the way to configure itself the right way. Good for newbies, but sounds like a long-winded process for something that should be quick and simple.

Another possibility would be to have some sort of configuration file (e.g. ~/.wordlessrc) where options could be stored in a global way. This would override the gem's default options. Specific options could still be specified manually.

Any thoughts on this? Other suggestions?

[emzo]

Indeed, the flexibility of WordPress installations is both a blessing and curse! The global config file sounds like a good solution though, I'd go with that personally. As you mention, it could simplify things by hiding many options, but still allows for total flexibility on a per-project basis.

I've found this article on Digging into WordPress to be a good resource on configuration options.

Some interesting work going on with wp-cli as well.

[etienne]

Messed up my commit message. This is not actually fixed.