Revive needs some very simple changes in order to deliver an acceptable installation/upgrade experience:
When it fails to write to an expected location, tell the user what location cannot be written to. At worst you could write a message to the error_log.
This is especially important because for whatever reason (a horribly misguided one is my guess) Revive's installer thinks it needs the absolute path from filesystem root—not from webroot—in order to perform an upgrade. So if Revive's installer may *think* it wants to write a file somewhere totally outside the webroot. Which is bad. Especially bad when you're instructing people to set permissions to 777.
Furthermore, even knowing that "the supplied Images Folder" is what couldn't be written to, where did that path get supplied from? If you report the path back that provides context so that the person reading the error doesn't bang her or his head against a brick wall trying to change the wrong directory. It doesn't matter whether the user or Revive is wrong about the path to the Images folder; it only matters that we know that we're tallking about the same folder.
Case in point: by editing InstallController.php at line 793:
$errMessage = $GLOBALS['strImageDirLockedDetected'].' {'.$aConfig['config']['store']['webDir'].'}'; // appended filename in brackets
error_log($errMessage); // new line added
I can see in the error logs that the Revive installer is checking the folder permissions on an empty string. There is simply no solution to this issue that inolves changing directory permissions or creating a directory. The instructions provided by the error message are flat wrong.
So with all due respect, Erik, your answer that users should learn to RTFM is dismissive and insulting.
In my case, in order to get the installer to move forward, I had to change webDir in the [store] section of my .conf.php to the absolute filesystem path. So that's a whole other issue: you should never need to know what the absolute filesystem path is.
Never.
Never ever.
There is no reason to. None at all. And it probably breaks all kinds of cross-platform requirements, and it looks like you're trying to compromise the security of the server, and potentially you could be enabling a security exploit. So stop it.
I have to congratulate Revive on the detail in the upgrade guide, but it could be written with a bit more attention to context. It's not clear, for example, that having two copies of the database is a suggestion while having two copies of the codebase is an absolute necessity. The first thing that I did was make a new dev instance on a virtual machine with a new copy of the codebase and a new copy of the database. And then I made a new copy of the database which was never needed.
Another copy of the database isn't a bad thing. The point is that the instructions were unclear enough about the process—despite the agonizing level of detail—that you ought to reexamine how those instructions are written.
It's all just suggestions here. It's free software and I haven't put the work into your software package to be in any position to make any demands. But hopefully free advice is, like free software, sometimes worth more than you paid for it.