Skip to content
This repository has been archived by the owner on Dec 20, 2021. It is now read-only.

Initial Requirements and Features #1

Open
austinpray opened this issue Sep 23, 2015 · 7 comments
Open

Initial Requirements and Features #1

austinpray opened this issue Sep 23, 2015 · 7 comments
Labels

Comments

@austinpray
Copy link
Contributor

Continuation of roots/roots-example-project.com#18

The base implementation will serve the following requirements:

  • Generate a sage theme starting point
  • Generate a bedrock scaffold
  • Generate a trellis install
  • Generate a project with all of the above

The goal being: start a brand new roots project and be up and running in one command. After this base implementation is accomplished, we can examine more features that will benefit other parts of a project lifecycle.

With the above requirements in mind, what features would you like to see?

Accepted Features

  • Trellis generator
    • Ability to specify 3rd party git remote
  • Bedrock generator
    • Ability to specify 3rd party git remote
  • Sage theme generator
    • Ability to specify 3rd party git remote
    • Ability to select your choice of CSS framework
    • Ability to rename references to Sage to whatever project theme name you want
@deegs
Copy link

deegs commented Sep 25, 2015

This is awesome - just inside the week I created a hacky shell script to jump start projects. 😄

For some features I'd like to see or that come to mind right now...

  • example.com variable replacement in group_vars
  • auto generate salts
  • ability to template out commonly used plugins, mu-plugins for composer?

I'll come back to this and give it some more thought.

@bluespore
Copy link

Overall, this is a great initiative guys. The Roots team have delivered marvellously to developers for WordPress implementations, but I've always felt the opinionated requirement of Bootstrap let it down.

IMHO a project that aims to scaffold a system for environments, deployments and CMS setup shouldn't necessarily drive the use of a front end framework because it's not necessarily related enough to the core goal.

That said @deegs out of curiosity, is it at all possible you could share your shell script?

I created one last year for our team to use with Bedrock and Roots (before it was 'Sage'), which worked pretty well but it took a lot of effort to get it functioning exactly how we wanted it; which included a fork of Roots sans-bootstrap references and used Yeoman to install a custom front end stack.

@retlehs
Copy link
Sponsor Member

retlehs commented Nov 2, 2015

but I've always felt the opinionated requirement of Bootstrap let it down.

have you looked at the starter theme lately? there's a few minor things you need to do in order to remove bootstrap and it should only take a few minutes max

the main goal of this project is not to provide options for front-end framework choices, although it will offer that at some point

@bluespore
Copy link

@retlehs No, I'm about look at the latest with Sage. I can appreciate that there may only be a few things that are required, but automation where ever possible is important in an agency environment, as it removes human error for each new project rolled out.

As I mentioned, my comments earlier were based on experience with a much earlier version and part of the task was removing any Bootstrap specific classes from the generated markup. It sounds like the process has improved a lot since then.

Thanks the insight on future development, and thanks for the hard work you guys have put into the stack so far as it's a great initiative and has been super helpful. 👍

@bluespore
Copy link

@retlehs OK just had a look through the latest Sage. Looks fantastic. Pretty minimal tie-in with Bootstrap compared to the initial Roots theme. You're right - it looks painless. Great work, dude. Thank you. :)

@nbyloff
Copy link

nbyloff commented Nov 19, 2015

I'd like to see configurable git repos, where you can choose what to checkout and where to place it. Like if I had a mutated version of sage with a bunch of my own custom features I wanted to re-use.

Optional choice to install nvm or bower on the guest. I have found myself in situations where I will use the install on the host for building the project assets, but some prefer to do the build on the guest.

@austinpray
Copy link
Contributor Author

@nbyloff yes definitely want to support the ability to specify a 3rd party git remote location. That will most likely be necessary for testing this repo anyway.

I want to stay away from installing ruby, python, vagrant, node, etc. for the scope of this project. Rbenv, virtualenv, nvm, and friends already do an excellent job of installing these environments as one-liners. If you find yourself repeatedly provisioning machines with nvm, bower, etc. then create some ansible playbooks or a simple shell script. Right tools for the right job.

This project will definitely give you extremely helpful pointers and maybe even link to installation tutorials if it detects something wrong.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants