Umm...
dovy opened this issue · 16 comments
Any ideas?
http://preview.simplerain.com/ovcY
Push rejected, no Cedar-supported app detected
I just saw this and realized my attempt to add the build pack failed. check your heroku config for the build pack url:
heroku config
It may ask you to specify the app name:
heroku config --app name-of-your-app
Tried a fresh install and fresh Heroku machine. Getting this:
http://preview.simplerain.com/pnJe
Would really LOVE to use this, but I am sad it's just not working.
Looks like your build pack URL is missing .git at the end.
Sent from my iPad
On Aug 14, 2013, at 11:34 PM, Dovy Paukstys notifications@github.com wrote:
@jerrod Any ideas?
—
Reply to this email directly or view it on GitHub.
@jerrod Made the change, same issue:
http://preview.simplerain.com/pohe
only other thing i see is that your git push is only pushing 218 bytes - which means perhaps you havent committed anything to the repo you're pushing?
➜ Sites git clone git@github.com:jerrod/wordpress-on-heroku.git
Cloning into 'wordpress-on-heroku'...
remote: Counting objects: 289, done.
remote: Compressing objects: 100% (213/213), done.
remote: Total 289 (delta 80), reused 250 (delta 64)
Receiving objects: 100% (289/289), 1.08 MiB | 1018 KiB/s, done.
Resolving deltas: 100% (80/80), done.
➜ Sites cd wordpress-on-heroku
➜ wordpress-on-heroku git:(master) rm -rf .git
➜ wordpress-on-heroku heroku create -n another-wp-test --account personal
Creating another-wp-test... done, stack is cedar
http://another-wp-test.herokuapp.com/ | git@heroku.com:another-wp-test.git
➜ wordpress-on-heroku git init .
Initialized empty Git repository in /Users/jerrod/Sites/wordpress-on-heroku/.git/
➜ wordpress-on-heroku git:(master) ✗ git add .
➜ wordpress-on-heroku git:(master) ✗ git commit -am "initial import for deploy"
[master (root-commit) 58e113c] initial import for deploy
153 files changed, 21411 insertions(+)
create mode 100644 README.markdown
create mode 100644 config/public/apc.conf.php
create mode 100644 config/public/phpinfo.php
..... and on and on .....
create mode 100644 config/vendor/php/etc/php-fpm.conf
create mode 100644 config/vendor/php/php.ini
➜ wordpress-on-heroku git:(master) ✗ git remote add heroku git@heroku.com:another-wp-test.git
➜ wordpress-on-heroku git:(master) ✗ heroku config:add BUILDPACK_URL=https://github.com/mchung/heroku-buildpack-wordpress.git
Setting config vars and restarting another-wp-test... done, v3
BUILDPACK_URL: https://github.com/mchung/heroku-buildpack-wordpress.git
➜ wordpress-on-heroku git:(master) git push heroku master
Counting objects: 183, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (173/173), done.
Writing objects: 100% (183/183), 1.06 MiB | 659 KiB/s, done.
Total 183 (delta 31), reused 0 (delta 0)
-----> Fetching custom git buildpack... done
-----> Wordpress app detected
-----> Installing Nginx v1.4.1
-----> Installing PHP v5.4.11
-----> Installing Wordpress v3.5.2
-----> Writing start.sh script
-----> Done with compile
-----> Discovering process types
Procfile declares types -> (none)
Default types for Wordpress -> web
-----> Compiled slug size: 33.6MB
-----> Launching... done, v8
http://another-wp-test.herokuapp.com deployed to Heroku
To git@heroku.personal:another-wp-test.git
* [new branch] master -> master
➜ wordpress-on-heroku git:(master) @jerrod You are fantastic. Your instructions worked without a flaw. Thank you. I've been racking my brain. Perhaps include this in the readme?
Next question for you. Updating wordpress/plugins. I tried updating wordpress which caused all kinds of fun (had to re-deploy).
What would you suggest as a proper workflow?
I always do everything localIy (upgrades, plugin installs) while connected to the production database so when i deploy everything is in place.
There are a few threads on here about local development workflows but as far as i know, no official way. I would recommend using nginx locally as opposed to apache as well.
I also keep the entire wordpress codebase in my repo (in public) and don't pull down the zip on deploy. this allowed me to apply the database reconnect patch and upgrade on my own schedule.
On Aug 15, 2013, at 11:24 AM, Dovy Paukstys notifications@github.com wrote:
@jerrod You are fantastic. Your instructions worked without a flaw. Thank you. I've been racking my brain. Perhaps include this in the readme?
Next question for you. Updating wordpress/plugins. I tried updating wordpress which caused all kinds of fun (had to re-deploy).
What would you suggest as a proper workflow?
—
Reply to this email directly or view it on GitHub.
Do you connect your local installation to the production database?? And what happens when you add/upgrade something and the database gets upgraded but you have not deployed yet? That could break the production site, couldn't it?
Drat. I have apache locally. That's going to be painful to reconfigure.
I did not connect my local code to the remote DB. I kept them separate.
Setup is always the most painful, isn't it. ;)
I deploy with the inactive plugin first - then connect to the db locally. I've never seen anything break doing this.
I only connect to the production database just before deploying. I know its scary, but with wordpress insisting on storing configuration data in the database instead of yaml/etc, there really is no other options since you can't alter the filesystem on heroku.
On Aug 15, 2013, at 11:38 AM, Dovy Paukstys notifications@github.com wrote:
Drat. I have apache locally. That's going to be painful to reconfigure.
I did not connect my local code to the remote DB. I kept them separate.
Setup is always the most painful, isn't it. ;)
—
Reply to this email directly or view it on GitHub.
Are you on OSX? use homebrew => https://gist.github.com/mystix/3041577
On Aug 15, 2013, at 11:38 AM, Dovy Paukstys notifications@github.com wrote:
Drat. I have apache locally. That's going to be painful to reconfigure.
I did not connect my local code to the remote DB. I kept them separate.
Setup is always the most painful, isn't it. ;)
—
Reply to this email directly or view it on GitHub.
I use Apache locally and I don't think that's a problem. The only downside
is that you are not able to test different nginx configurations, you have
to deploy them. But if you don't need to configure nginx you are fine using
apache.
I don't use memcachier either so I usually do a "git update-index
--assume-unchanged object-cache.php" and delete the file.
On 15 August 2013 17:38, Dovy Paukstys notifications@github.com wrote:
Drat. I have apache locally. That's going to be painful to reconfigure.
I did not connect my local code to the remote DB. I kept them separate.
Setup is always the most painful, isn't it. ;)
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/31#issuecomment-22711137
.
@jerrod @luisherranz Thanks for all your help.
How would I update wordpress as the current config relies on the s3 pre-compiled binaries?
Updating a plugin/theme, that's pretty strait forward. Thanks for all the advice. I'm really just confused about wordpress 3.6 now. ;)
you can override the version. see the last comment here:
On Aug 15, 2013, at 12:26 PM, Dovy Paukstys notifications@github.com wrote:
@jerrod @luisherranz Thanks for all your help.
How would I update wordpress as the current config relies on the s3 pre-compiled binaries?
Updating a plugin/theme, that's pretty strait forward. Thanks for all the advice. I'm really just confused about wordpress 3.6 now. ;)
—
Reply to this email directly or view it on GitHub.