themejuice / tj Goto Github PK

I am not very familiar with using Vagrant do you actually need to add a default vm to it first before running theme-juice?

I keep getting the following error:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'base' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'base' (v0) for provider: virtualbox
default: Downloading: base
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

Couldn't open file /Users/username/base

I tried to resolve by:

1. cd to vagrant install directory and run: vagrant init hashicorp/precise32
2. run: vagrant up
3. then setup/create theme-juice project

Even though this is done do I still need to provision? https://docs.vagrantup.com/v2/getting-started/provisioning.html

Vagrant seems setup up but as far as I can see does not see the Customfile as the project is not synced nor is the network up?

Also theme-juice-cli seemed to create everything fine with no error I have the complete log if you want to see it?

I am very interested in getting this all worked out and having the steps very clear as I am developing a new workflow for our team members!

What am I missing here?

Right now, the error message isn't helpful. When an invalid character is given, let's pass it into the error message. 👍 The 'only ASCII chars` line is also ambiguous., since we're really only allowing letters, numbers and dashes, which should be stated there instead of 'only ASCII'.

Rename tj-config.yml to just tj.yml, with the option to make it a hidden file, too. No other config files use the word 'config' in the filename, so we should probably ditch it for consistency.

Not sure if this is even needed, but would make setting up a previous projects development environment simpler. But then again, it only takes a few seconds to input these settings on a tj setup.

site_name: site
dev_url: site.dev
db_host: database host
db_name: database name
db_user: database user
db_pass: database pass

Since this isn't always the default, it should be an option on create.

Not sure why, but most commands that come from git, vagrant and npm seem to make it to $stdout even though it's muted via --quiet. Not sure what the deal is here.

open https://github.com

Probably shouldn't ask this on Windows, since I don't think it has an open command.

Maybe something like a YAML file. This would be used for starter theme developers to execute scripts that are relative to that theme. Example, if somebody wanted to use Grunt as a watcher over Guard.

watch: grunt
server: cap
vendor: composer
install:
    - composer install
    - gulp dist

Default settings for Slack via it's load:defaults task do not get loaded. Including them inside of the invoke process overwrites previous config settings. I imagine this is an issue with any plugin that uses the load:defaults task, since we're never explicitly invoking it like Capistrano normally would.

Currently not worth it to maintain support for WIndows when simple things like shell menus and unicode fonts cause the whole app to fail. 👎 maybe in the future.

This results in a failed first deploy. A task should be created to create required shared files/folders automatically.

Not sure if we can run commands from it, but it would be awesome to be able to use the dashboard as a GUI. As long as tj is installed on the VM, I don't see why this wouldn't be possible. Running the commands inside of the VM would also kill off any issues with Windows and Ruby versions.

# Change all tj methods to Thor's say method
::ThemeJuice::message "message", "color" # => say "message", :color

This will get rid of the colorize dependency and make the code easier to manage.

vagrant landrush rm #{@project.name}

So, as it is right now, setting up a deployment is rather confusing, since there's a lot of options that need to be changed, and a lot more options that don't need to be changed. Using ERB (or similar) to write into the config/ dir via a new tj config command would be great.

Example, running tj config deploy would allow you to add your deployment configuration (server info, stage, slack tokens, app name, git repo, etc.), all while never actually having to edit the files yourself. The only issue is that deployment is starter theme dependent, so creating a deployment script that could vary is the tough part. The questions could be pulled directly from the ERB files, but that might get messy.

Food for thought.

Would just be a simple conditional depending on which one is installed (favoring Landrush if both).

if defined? VagrantPlugins::Landrush
  config.landrush.host '#{@project.url}', '#{@env.vm_ip}'
elsif defined? VagrantPlugins::HostsUpdater
  config.hostsupdater.aliases << '#{@project.url}'
end

For example, when deploying to production (and only production), we want to exclude the robots.txt file. Allowing an additional excluded files array might work to remedy this problem.

Need to use literal Unicode character source code, such as → as \u2198. Windows seriously doesn't like these things... so at least adding that and the encoding line below allows it to be installed.

#! ... shebang
# encoding: UTF-8

Look into:

• xip.io
• Issue on VVV about connecting to VM from mobile
• Vagrant Share

Thor has class_option that we could take advantage of. This would be for both Windows users (who can't utilize ~/), and users who install VVV in anything other than ~/vagrant.

Automate all the things!

Mainly concerning the gem description; it's just way too wordy.

There needs to be a few checks to make sure that this path is never an absolute path. I don't want to ever destroy a root directory due to a leading slash.

To update all Vagrant plugins, and VVV itself (git pull). This would of course be after doing a gem update theme-juice, to get the newest stuff. This could also update tj within VVV (if we go that route).

If you try and install to an existing empty directory by typing full path:

• Where do you want to setup the project? : (/Users//) /Users//Sites/
theme-juice will fail:
… Cloning theme
fatal: destination path '.' already exists and is not an empty directory.

I think it should at least be more clear to actually cd ~// then run theme-juice and only specify the folder name to create if it exists then maybe ask what to do eg: run anway?

This had me stumped at first.

Below is the error received when building latest gemspec file:

$ gem build theme-juice-cli.gemspec 
Invalid gemspec in [theme-juice-cli.gemspec]: cannot load such file -- highline/import
ERROR:  Error loading gemspec. Aborting.

More info:

$ gem build theme-juice-cli.gemspec --debug
NOTE:  Debugging mode prints all exceptions even when rescued
Exception `LoadError' at /Library/Ruby/Site/2.0.0/rubygems/core_ext/kernel_require.rb:54 - cannot load such file -- thor
Exception `LoadError' at /Library/Ruby/Site/2.0.0/rubygems/core_ext/kernel_require.rb:54 - cannot load such file -- highline/import
Exception `LoadError' at /Library/Ruby/Site/2.0.0/rubygems/core_ext/kernel_require.rb:133 - cannot load such file -- highline/import
Exception `LoadError' at /Library/Ruby/Site/2.0.0/rubygems/specification.rb:1045 - cannot load such file -- highline/import
Invalid gemspec in [theme-juice-cli.gemspec]: cannot load such file -- highline/import
ERROR:  Error loading gemspec. Aborting.

Have you received this error?

The config command definitions could be simplified and be modified in such a way that would allow custom commands to be defined within the Juicefile. This could be used to manage sites other than WordPress using their specific CLI tools e.g. Mage, Ember, etc.

# ...

desc "install", "Run theme installation"
def install(*args)
  @config.command :install, args
end

desc "watch [ARGS]", "Manage development build tools"
def watch(*args)
  @config.command :watch, args
end

desc "assets [ARGS]", "Manage front-end dependencies"
def assets(*args)
  @config.command :assets, args
end

desc "vendor [ARGS]", "Manage back-end dependencies"
def vendor(*args)
  @config.command :vendor, args
end

desc "dist [ARGS]", "Package project for distribution"
def dist(*args)
  @config.command :dist, args
end

desc "wp [ARGS]", "Manage WordPress installation"
def wp(*args)
  @config.command :wp, args
end

desc "backup [ARGS]", "Backup project"
def backup(*args)
  @config.command :backup, args
end

desc "test [ARGS]", "Manage and run project tests"
def test(*args)
  @config.command :test, args
end

# ...

If Thor allows, all of that could be simplified into a simple loop using the @config.config.commands hash, defining the config command methods at runtime.

Highline prompts don't obey the --no-unicode and --no-colors flags, since they're not passed through the UI.

Edit: also in the error output for remove_traces_from_file method.

Stupid 👎 capturing $stdout but it's still getting through when running Git/Vagrant commands.

Do it.

I'd like to fork VVV and make adjustments that would ease development using tj, such as being able to select and modify PHP and mySQL versions. I'd also like to get rid of all of the default WordPress installations, as they're never used and they cause the provisioning to take way too long.

I've already forked the VM and have begun using the fork, so I'll create a develop branch and start work when time allows. I'd also like to create a unique GUI dashboard to create sites, as mentioned in #25.

• Streamlined Linux box
• Remove default WP installs from VVV
• WP-CLI, Composer, PHP, MySQL, Apache
• Ability to change dependency versions e.g. PHP, MySQL, etc. (https://github.com/phpbrew/phpbrew)
• Useful VM dashboard where you can manage (and create?) projects (creating desktop app)

If possible, this should be done in a backwards compatible way; where users can git pull the up to date VM without breaking existing development projects. I'm marking this as a breaking change just in case.

All of the current issues on Windows are actually a result of using the ~/ path. If global state was kept in a .tj-config file, we could have VVV installed into custom locations, so using the home path wouldn't be necessary, since it's assumed VVV is always and will always be installed into ~/vagrant.

To avoid any future headaches with the rather crude auto-removal of the tmp deployment directory, let's implement a boolean value that is defined within the Juicefile deployment settings.

Too many files get transferred. Lets simplify this down to a single zipped directory. This needs to be handled for all operating systems (e.g. needs to support Windows).

One of it's dependencies require Ruby ~> 2.0. Would probably be a good idea to only require test-related gems for Travis to avoid stuff like this in the future.

Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies...
Using bundler 1.7.6
Installing docile 1.1.5
Installing rake 10.4.2
Installing simplecov-html 0.10.0
Installing diff-lcs 1.2.5
Installing fakefs 0.6.7
Installing i18n 0.7.0
Installing json 1.8.2
Gem::InstallError: mustache requires Ruby version ~> 2.0.
Installing hpricot 0.8.6
An error occurred while installing mustache (1.0.1), and Bundler cannot
continue.
Make sure that `gem install mustache -v '1.0.1'` succeeds before bundling.