Hi,
When you installed git, did you check the option to allow the script to be used by all paths?
Most of the time when this happens it’s because the path to Git isn’t set in the Apache environment.
Yeah, this helped! (Or the necessary reboot, after setting the variables according to this link: http://blog.countableset.ch/2012/06/07/adding-git-to-windows-7-path/ )
Anyway, revisr is now connected to the local git repository.
I then changed the permissions on the .git folder and the uploads folder and also added C:\XAMPP\mysql\bin (I tried it with and without \ at the end) to the revisr settings, but I can not get my database backup to work (local).
Any ideas?
Hi Felix,
Sorry for the delay on this, I didn’t see your response until now.
I just posted an answer to a similar thread here that should help with this issue:
https://wordpress.org/support/topic/error-backing-up-dabase?replies=3#post-6509157
Hello ExpandedFronts,
thanks for the reply.
I read the other post and tried the mentioned way of finding the correct path, but without luck.
I will for now stay with revisr, but only to do the commits on the server. I am doing a manual export of the database and put it into a folder in the git root, so its versioned, too.
Its not the best solution, especially now that I am close to the file size limit of the file to be imported, but its working for now.
What a pitty.
If there will appear another solution or idea what could cause the problems, I will be super happy about a note here.
Thank you once again for the plugin and all the help so far.
Felix
Hi Felix,
I’m looking into adding a fallback to the WordPress database class for running backups.
Just as a bit of background, the reason why it’s set up the way it is now is because just passing the sql exports through to MySQL is always going to be faster and won’t tie up PHP too much in the process. Other popular plugins like VaultPress have the same approach.
Currently, the fallback to WPDB is only occurring for imports, the focus for me has been on testing that and making sure it’s feasible in terms of performance.
I haven’t seen or heard of any issues relating to that, which means that either the fallback isn’t being used, or it is being used and works well. So for me the next step is adding a similar fallback to exports, which should resolve issues like this and reduce the amount of troubleshooting necessary.
I’m also adding a ‘debug’ page in the next release which will run a lot of the troubleshooting for you.
Please don’t hesitate to let me know if you have any further questions or feedback in the meantime. Thank you.
Hello Expanded Fronts,
thanks for the clarification!
If you need any help in testing, let me know and I will give it a shot with my setup.
A troubleshooting page will be an amazing feature, looking forward to this.
All the best,
Felix
Hi Felix,
When you get a chance can you test out the latest release and let me know if the issue persists? Thanks!
Hello Expanded Fronts, I updated your plugin now, and the first thing I noticed is, that I can not more access it 😀
This is due to
define( 'DISALLOW_FILE_EDIT', true );
or/and
define( 'DISALLOW_FILE_MODS', true );
that I have in my wp-config.php to disable file modifications from the dashboard.
On most other plugins the settings option simply disapears but for revisr it wont but I can not access it with the message that I have not enough rights to access that page.
Same is for accessing the plugin direct (via the symbol).
settings this both lines to false makes revisr work like normal.
Regarding the other problem, I will test it now and respond here again, asap.
Cheers,
Felix
Hi Felix,
Thanks for testing that out and letting me know about that issue. It looks like the problem is just due to the following:
define( 'DISALLOW_FILE_MODS', true );
In the latest release I updated the plugin to only load any admin-related hooks for users that can install plugins. The DISALLOW_FILE_MODS constant appears to remove this capability. In hindsight I think it makes sense to make this a configurable option or filter, an added benefit would be limiting access to Revisr to certain roles or users, etc.
Hei there.
you are right, ‘DISALLOW_FILE_EDIT’ does not influence the behaviour of revisr, but ‘DISALLOW_FILE_MODS’ does.
I agree, limit the access to revisr for certain roles makes sense and I think is the better way of solving this problem.
For the local backup of the database, I did not have any luck until now. I tried it only one time now, and I am not sure if I missed some settings. In the help is written, that the mysql install path could not be found. The rest was detected correctly.
Overall impression is quite good, congratz for the update!
edit:
In the help tab, the operating system was detected as Windows NT. I am using Win 8.1 and XAMPP, not sure if there is somewhere in between some Win NT? Just for the case that is of some importance…
Hi Felix,
If it’s saying that the MySQL path couldn’t be found, then it’s likely that the MySQL Path setting just needs to be tweaked if backups still aren’t working. Since you’re in Windows, using XAMP, it looks like the correct MySQL Path to use would be as follows:
C:\xampp\mysql\bin
if that doesn’t work, you might be able to find the correct path by typing in which mysql in command line and if the result looks like C:\xampp\mysql\bin\mysql, you’d just type in C:\xampp\mysql\bin\ into the settings.
The results on the “Help” tab are just static checks for the environment paths, so they won’t update when you change the paths in the Revisr settings.
Regarding Windows NT/Windows 8 – that’s just how PHP sees your operating system, and the results showing up as Windows NT would have no different affect than it showing up as Windows 8.
Let me know if you have any questions, thanks!
Hello.
I tried the where command and it said:
C:\xampp\mysql\bin\mysql.exe
So I tried to put
C:\xampp\mysql\bin\
as path to mysql but revisr removes the additional dash at the end and with
C:\xampp\mysql\bin
it does not work. (Is there anything else I need to set?)
I assume that revisr reads the database user name and password from the wordpress variables for it, right? It might not be a problem that these are different for local and life installation?
I do load them via an external file, wp-config-local when I am in the local installation.
Some extended error message on why the database backup failed would be great.
I found some other problem, when trying to use the Revisr Webhook, I can not see the full URL, as the textfield is to small. And as it is readonly, I can not mark and copy it. (With “inspect element with firebug” I can see and copy the full URL, though).
Anyway, pasting it in the local version of my wordpress installation and clicking save results in a completly destroyed url. seems like url encoded, but without %-signs and spaces instead.
I am not sure if I need it, so its not that bad for me, but wanted to let you know.
Cheers,
Felix
Thanks for the heads up.
It looks like the issue with the database backups and the Revisr webhook are related and might be XAMP/Windows specific as I’m not able to replicate on Mac or Linux.
I’ll test this out on a Windows machine with XAMP and get back to you.
Watching and waiting patiently… Having the same problem running the DesktopServer/XAMPP combo.
