Bedrock: a modern WordPress stack
github.com
github.com
Upshot, though, there's plenty of documentation and SO threads out there and a huge ecosystem of plugins. Most of the time you never even need to look at the actual source code.
<?php /* pointless comment */ ?>
<?php echo $something; ?><div><?php if($blah){ echo stuff(); ?></div><?php } ?>...
Everything else is just accidental complexity.
https://github.com/WordPress/WordPress/blob/master/wp-includ...
"composer install" will install from composer.lock.
This is my primary new WP project approach (which isn't perfect):
mkdir Example-Project
cd Example-Project
# Grab the latest wordpress, www is our DocumentRoot
curl wordpress.org/latest.tar.gz | tar -xvz --
mv wordpress www
cd www
# Drop the default wp-content and symlink so we dont need to
# keep all of wp in Git
mv wp-content ..
ln -s ../wp-content
echo 'www/' >> .gitignore
# Make the repo
git init
git add . && git commit -m 'First!'
Seems like your issue has to do with your symlink setup. We don't need to do any special configuration with the web server. Here's the configuration that deals with app/: https://github.com/roots/bedrock/blob/master/config/applicat...
Does it do the whole autoloader song and dance with Composer?
Example: If I add Guzzle to Composer, can I call it from my plugin's code the way you can with other frameworks?
Only thing I would change is to swap out Capistrano with Fabric. But that's a personal choice.
But in the example you gave, ideally your custom plugin is itself a Composer package which requires Guzzle in its composer.json file. Then you'd require your plugin in the project's composer.json :)
Re: Capistrano. We're really trying to encourage people to fork this and modify it to their needs. So you could easily rip Cap out and integrate Fabric in your own fork. We're just providing some sensible defaults that we're familiar with.
If you're interested in work to do with WP/Roots you can check out this thread on our forum: http://discourse.roots.io/t/looking-for-work-post-your-info-...
It's usually not a great idea to let normal users install plugins and update WordPress. For an analogy, you definitely wouldn't have users installing Gems in a Rails app.
that's not the same thing, Installing a gem wont magically add a feature to your rails app. Non developpers cant do it either(let alone deploying any ruby app on a server).Installing Plugins on wordpress dont require any developper knowledge.
Plugins should be installed on dev/staging and tested before just adding them in production. Plugins in WP are a double-edged sword.
It was posted here a few months ago: https://news.ycombinator.com/item?id=6504878
Only thing I don't like is the renaming of the root `wp-config` folder to `app`. I'd much rather have the app reflect the underlying wordpress conventions than to change it to look like something else. Yeah, consistency, but boo for barrier of entry or having to remember that `app` == `wp-config` when not everything we get to work on will get to use the shiny fandangled tool.
How do you guys handle database syncing / deployment / rollback (if at all)?
We don't do anything about DB syncing for now. That's next big thing once we get the Vagrant/server config work done. It's a popular topic but also complicated since everyone has different use cases.
Thanks!!