How do I pull from heroku?
I have wordpress running in my heroku app and i changed some stuff via the template editor.
I'd like to have these changes also locally.
When i try to pull from heroku i get the message:
Already up-to-date.
But I don't have these changes locally
It's normal to get the Already up-to-date message, since the remote changes weren't commit and pushed.
Since you cannot commit and push from Heroku, you need work locally and then deploy. And that's how you should work at first place.
What did you change with the template editor? Probably configuration, and not code right? So if you do a pull from Heroku, you're not going to see changes? (I'm not familiar with wordpress - but I doubt the template changes result in code changes). So I guess I'm hypothesising that it's right: there are no changes.
Perhaps what you really want are database changes?
By the way, you can now clone a Heroku app with the new heroku git:clone
What does git branch -r --no-merged return? If it returns any branches, it means those branches have changes you don't have in the current branch yet. Merge them to get the changes.
Otherwise, the thing you are pulling does indeed not have any changes. That can mean that the changes you are looking for in another branch.
What you might want to do in that case is git fetch <heroku> where heroku is the name of the remote pointing to the heroku repository. That'll fetch all banches from heroku, which you then are able to merge.
Related
There are many wonderful tutorials describing in great detail how to set up a horizontally scaled WordPress install in AWS' Elastic Beanstalk - that part is no problem. But I haven't found any follow-up advice yet on how to manage plugin updates after the initial setup, let alone updating wordpress-core itself. Does anybody know the most optimal way to do this?
This is the methodology I'm using so far, but I'm not sure if it is the best way:
Download the plugin's update file and unzip it. Remove and replace the relevant folder in /wp-content/plugins (local git repo)
Run the update in the live site like normal - to ensure that any database changes get pushed up to the RDS
eb deploy from the local repo to commit the file changes and make the update persistent
Is that a sane method? Could anything get corrupted down the line?
For updating wp-core, the tutorials I've read seem overcomplicated - basically rebuild the site from scratch every time an update comes out. Below is what I have been using (used it successfully for WP 5.0.2). Is there any chance of files and databases getting out of sync using this method?
Download and unzip the new wordpress version locally
Replace wp-admin, wp-includes, and the root files except for wp-config.php (local git repo)
Run the update in the live environment, so that any database changes get pushed up to RDS.
eb deploy
I've been running with the above methods for a while and feel pretty confident that they are sound. I only have a couple of tweaks thus far.
The following assumes an environment where there is one staging server outside of the horizontally scaling live environment. This could be further improved for a multi-developer environment using AWS Code Commit.
For Plugins:
Run the plugin update normally on the staging server (in wp-admin). Test everything to make sure the update is sound.
Remove the plugin's old folder from your local git repo and download the updated folder from the staging server using SFTP.
In the local repo, run git add -A && git commit -m "updated Plugin Name" && eb deploy
Run the same update in Live (in wp-admin). It will only apply to one server, but should guarantee that any database changes get pushed up to the single RDS.
Roll out the change to the live environment using the Software Versions page in the AWS Console (in Elastic Beanstalk)
Updating WP Core is almost identical except that instead of removing and replacing a single plugin directory, you will need to remove and replace /wp-admin/, /wp-includes/ and all of the files in the root folder except for wp-config.php
My team will be working on a Wordpress project (theme), and we're looking to build using the Foundation CSS framework. Additionally, we will be making use of Git as source control.
We've discovered the Foundationpress theme, and would like to use it as a starting point: https://github.com/olefredrik/FoundationPress
We would only want to do this once in a while, ie maybe there is a bug in the current version that gets fixed.
My question is, how can we keep up to date with changes to the Foundationpress theme selectively?
ie: Should I fork the project, and change the remote origin to our Github repository, and add a secondary remote for the Foundationpress repo, and then only pull down changes from the Foundationpress remote when needed? I'm just not really sure what the best practice is.
Maybe there's a better way to handle this entirely. Thank you!
Even if you fork the olefredrik/FoundationPress, your fork repo will not contain the update changes that olefredrik/FoundationPress made.
If you don’t need to contribute for olefredrik/FoundationPress, and you already have your own remote repo you want to work on, you can directly add remote by git remote add upstream https://github.com/olefredrik/FoundationPress.git, and check if there has update by
git fetch upstream
git log master..upstream/master
If there has output, that means olefredrik/FoundationPress has new commit(s) which is(are) not contains in your local repo. You can use git pull upstream master to pull the new changes.
If you need to contribute for olefredrik/FoundationPress or you don’t have your own remote repo, so you can fork it and check if there has update changes by the same way above.
To deploy a meteor app, you enter meteor deploy my_first_meteor_app.meteor.com
To update the deployment, is there a faster way than typing the above command again? It's quite tedious if you have a long domain name like the one in this example.
Yes. You can user aliases (nothing to do with Meteor). This is how you do it on a Mac:
alias new_name='command to be performed'
After which you must store the changes permanently in the file:
~/.bash_profile
See a full explanation here: http://www.maclife.com/article/columns/terminal_101_creating_aliases_commands
Also, you can try running meteor deploy without the site name. I don't remember if that works or not though. meteor deploy does remember old settings files that were used, but I'm not sure if it remembers the site name you used too.
I've spent a few weeks on this one, and I'm finally giving in and asking for help. I think I've tried just about every method I've seen suggested in other posts and tutorials, however nothing seems to be working. Anyways, here is my setup-
I have a git repository stored on BitBucket that is my local repo. I want to push my changes to my remote production server (and also staging), but for now lets focus on making one work. The way I have the remote server set up is by using a post-receive hook outside of my public_html folder. The folder is called repos and the bare repo is called development.git. The post receive hook inside repos/development.git is simple enough-
#!/bin/sh
GIT_WORK_TREE=/home/peterj05/public_html git checkout -f
I added the production server as a remote inside my local repo as "production" and push to /myserversaddress/repos/development.git, and the post-receive hook then transfers it to my public_html folder where I want it. The problem is that I have Wordpress added as a submodule and that the submodule does not get pushed along with everything else.
I've tried adding
git submodule init
git submodule update
to no avail.I've also tried some other methods, but either I'm screwing things up (which is entirely possible. While I'm not new to Git, I'm no expert by any means, and sometimes need things spelled out for me). Deployment options especially are new to me, which is why a lot of this has been so hard.
I'm willing to try just about any method, other than the pay service deployment options out there.
I'm at the end of my rope here. I've read so much and nothing seems to be working. I have to be missing something here. I am also pushing recursively in case anyone is wondering.
-P.J.
As you should see in the images below, the css on my local host site is spaced much better at the top than it is on heroku.
Has anyone had this type of problem before. You can see it best on this page http://pltcpal.herokuapp.com/forums/
I'm using Twitter bootstrap, which recommends adding
`padding-top: 40px;`
to body if using the top nav bar. Somehow it's not working...
The problem is related to the handling of the asset pipeline on Heroku. There are several ways on how this can be handled, see http://devcenter.heroku.com/articles/rails31_heroku_cedar
I fixed the issue in my application by pre-compiling the assets locally on my machine and then pushing them to Heroku.
Pre-compile the assets:
RAILS_ENV=production bundle exec rake assets:precompile
Add/commit the changes to git repository:
git add public/assets
git commit -m "vendor compiled assets"
To be safe I tested the whole thing on a local branch on my machine first which I pushed to Heroku using the following command (Heroku normally ignores all branches except the master branch, thus the trick):
git push -f heroku heroku-assetpipeline:master
FWIW, I had this same issue and checked everything I could think of, as well as those above. It turned out I must have zoomed out in my browser while on localhost, and I had the standard zoom on my production url.
It was as simple as resetting the zoom in my browser on both pages. Hope this helps someone else with the same problem.
I have the very same issue.
When I compare the development and production code, it occurs that on the development machine the stylesheets and javascript files from bootstrap all get loaded whereby on the production site (Heroku), there is only one application-XYZ.css and one application-XYZ.js.
I am not sure if this could be an issue with the asset pipeline.
Could probably someone elaborate on what needs to be done to (pre-)compile the asset pipeline such that deployment on Heroku succeeds.
Is it possible that you pre-compiled your assets locally at some point? To force heroku to compile your assets during slug compilation you can rename your public/assets/manifest.yml to public/assets/manifest.yml.bak, commit your source, and push to heroku.
Heroku assumes you compiled your assets locally when it sees the manifest.yml file.
I had this same problem and followed the instructions of a couple of different pages including Heroku's own documentation. I'm posting here to help the next guy because possibly due to changes in Rails 4, Heroku, or Github but the above directions did not work at all for me. However I did get it to work and here's how.
Yes you probably should precompile your assets using RAILS_ENV=production bundle exec rake assets:precompile but after that go into you 'public/assets' folder and copy "all" '.css','css.gz', '.json', '.yml', '.js' files that start either with 'application' or 'manifest'. Move them to a folder outside of the application's directories. Do this just encase anything goes wrong. Verify all of those files are deleted from the apps 'public/assets/' folder. Next restart your local rails server and verify your app is still behaving as you intend it to. Then go to your Github account and go into the 'public/assets/' directory of your repository and delete all the same files that you just did locally. Then add/commit locally, then push to git, then to heroku, and walla you're done it should be working.
The rationale behind it, what I assume, is because when you push to Heroku it checks for compiled assets in your repository and because of this, even though I had precompiled locally, it was still pulling some asset configurations from previous commits. By removing these files, Heroku must compile them during the push. One thing I didn't try which may work is just switching to another branch and deleting those files and deploying that branch to Heroku, so you may want to try that first, but this is what worked for me.
One other note, renaming the files to .bak or .old Heroku still considered them as their regulars and displayed them as it was the original ones that were not displaying properly.