Expanded Fronts

Hi Michael,

Thanks for reporting this. It looks like this is actually the default behavior of Git (regarding symlinks), instead of a bug with the Revisr plugin.

However I’m leaving this open for now while we look into some possible solutions and update docs as necessary.

In the meantime, the easiest solution would likely be to use the normal WordPress structure (without the symlinks to “wp-content/uploads”.

Hi Michael,

There are actually two available methods. On the Database settings screen, you can select whether you want it to perform backups using mysqldump or by using pure PHP/WordPress database functions.

It backs up each database table to it’s own file, so that a change to one table won’t require the entire database to be committed again.

You can find these files in the wp-content/uploads/revisr-backups directory.

Hope that helps!

Hi,

Sorry for the misunderstanding, if you’ve already added your id_rsa.pub to Gitlab you shouldn’t need anything else to push via SSH.

The fact that you’re able to push locally/outside of Revisr and the fact that other Git functions are working correctly within Revisr indicates that the user running Apache doesn’t have access to the SSH keys you’ve generated on the server and added to Gitlab.

Normally this means that Apache is running as “www” or “www-data”, while you generated your keys for the user that you logged into your Mac/PC with. The solution here is to either get Apache running on the same user, or to switch to HTTPS for pushes/pulls on that environment (as shown above).

Let me know if you have any questions on this or run into any further issues. Thank you.

Hi,

I haven’t used Gitlab, so it’s hard to say for sure (I will try out the community version over the weekend).

I did find this article that goes through setting up https on GitLab:
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md#using-https

Once you’ve got that configured, you’d just need to set up the username and password in Revisr as shown in the docs. To answer your question about the SSH, yes if you’re using SSH you will generally need to add your public key to the server (in Bitbucket or GitHub, you add the public key through their web interface).

With exporting/importing the database, currently it overwrites whatever tracked tables you have. It does allow you to decide which tables you want to track/export/import, so you could ignore tables with more activity, or ignore a table from being pulled in on a specific environment.

Alternatively you could pull the production data down onto stage before doing a push up to production if you have a lot of DB updates to do. Revisr makes it possible to always have the latest data on any server by just doing a pull with the “Import DB when pulling changes” option checked.

@sivakumarp Can you please open a separate thread with the full copy/paste of the error you got? The file and line numbers in the error should help out a bunch.

Hi,

Can you please confirm which version of Gitlab you’re using? Selfhosted or cloud on Gitlab’s servers?

Can you confirm the Apache user is the same as your Mac user? Are you using MAMP or something similar? The most likely culprit is that Apache doesn’t have access to your public key, if it’s running as www or apache. In this case HTTPS is the simplest solution.

Sorry for the additional questions, all the info you provided above looks good.

Hi,

Can you paste the error details that comes up when you click “Click here for more details”?

Are you able to do everything else in Git ok from within Revisr (commits, etc?).

Can you paste the debug info from the help tab?

Are you using SSH or HTTPS to connect? If SSH, does the user running the server (apache) have access to the SSH keys generated for the remote repo?

Let me know on the above. Thank you.

Hi, responded via email and marking this thread as resolved while we work on your setup externally.

Hi,

Nope :), “origin/master” is just how you would refer to the “master” branch on a remote named “origin” (which is what most remotes are named by default in Git).

If you set up Revisr and are on local branch “master” and have it connected to a fresh Bitbucket repo, and then do a “Push Changes” from within Revisr, it will automatically push to the “master” branch on the remote (which could be referred to as “origin/master”.

But you don’t need to actually specify any of that in Revisr as long as the remote is set up correctly (and you’d see errors when pushing/pulling if not).

Hi,

Sorry for the delay. Documentation in this area is being worked on and will be updated this week. I’ve added some quick steps below that should work for most setups.

Before doing anything, make sure you have a backup of your site files and database. It is currently possible to mess up your data if you’re not careful or aware of what you’re doing.

• Install Revisr on your dev site, creating a new repo if necessary
• Configure the “Files/Directories to ignore” (usually add the wp-config.php, .htaccess, and other environment-dependant files here – this updates the “.gitignore” file for the repo)
• Commit any pending/untracked files via “Revisr”->”Commits”->”New Commit”
• Configure the remote repo in the “Revisr Remote Settings” section
• Push to the remote from within Revisr
• Manually upload the “.git” folder and the “.gitignore” from your dev site to production (this is only necessary once)
• Install Revisr on production
• Make a commit on dev and push it up to bitbucket/github, production should see this and you should be able to pull this onto production. You could then also make a commit on production and push it up to bitbucket/github, and pull it down on dev

The above implementation would just be a basic files only, non-automatic deployment setup, but once you have that set up it is easier to configure some of the more advanced settings such as the autopush/autopull and database import/export settings.

One of the key things to note is that for most smaller to medium sized setups, it’s easiest to keep it all on a single branch, that way you can just do pushes/pulls without worrying about merging.

If you need any more help setting this up feel free to shoot an email to [email protected] with more details on your specific setup, and stay tuned for updates to the docs over the next few days.

Let me know if you have any questions, thanks!

Hi,

Yes, the plugin supports the scenarios that you posted above.

For example you could have Revisr installed on https://www.example.com, tracking branch “master” that is tracking remote branch “origin/master” (usually Bitbucket/GitHub).

If you update a plugin directly from the wp-admin on https://www.example.com, or use the code editor, you’d be able to commit these changed files and push them back up to “origin/master”. Alternatively you could upgrade the plugin on Bitbucket/Github/outside of Revisr and then use Revisr to pull those changes in.

In other words, since it’s using Git repos, it will detect any sort of file changes on the environment it is installed on. But you can also pull down any changes from a remote repo as needed.

Marking this as resolved, but feel free to let me know if you have any further questions or if I confused your use-case at all. Thanks!

Hi,

If you just want it to pull commits, you don’t need the Bitbucket “Pull Request POST” hook, but the one above that in the dropdown, which is just a standard “POST” hook.

The standard “POST” hook is the one that fires for each commit, which sounds like the one you’re looking for.

Marking this as resolved for now, but please let me know if you run into any further issues. Thank you.

Glad you got it working! I’m planning on revamping documentation this week, so I’ll make sure the solution above gets added to the docs. Thanks for posting that here!

Hi,

In the situation described above, you would do something like the following:

1. Backup the database on production
2. Log in to dev and pull down the changes, importing the database (make sure to set the “Development URL” to the WordPress “Site URL” for the production site, so it gets search-replaced)
3. Update WordPress on dev
4. Test and commit the changes, pulling them back up to master (or staging if you have a staging site in the middle).

For smaller sites/setups, I prefer to keep all sites running on the same branch. This is likely the easiest method for getting the changes on multiple environments, since you can just do a standard “Pull Changes” from within Revisr.

I saw the issue you opened on GitHub for better documentation in this area and definitely agree. I’ll take a look at it this week and will let you know as I have further updates.

Hi,

Another user reported issues with the GoDaddy linux plan and I’ll be spinning up a test plan today to troubleshoot further.