Jump to content

smscotten

Approved members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by smscotten

  1. Erik, I'm not blaming you that the instructions "don't match". I'm saying that in your eagerness to make the instructions include all possible levels, you went far enough that it backfired and that they lost clarity. I know that the second copy of the database isn't necessary. I'm just saying that it was not clear from your instructions which steps were necessary and which steps were helpful hints. But stop right there if you are saying that the "Directories Must Be Writable" issue is the result of something I did differently from the instructions. I did not stray from the instructions until I encountered a problem where the support forum (here) had the author (you) responding to another user (tobean) with the same problem with a response that was, if polite, dismissive. You made it absolutely clear that you did not bother to read his or her report. Tobean wrote: "I have also changed all directories and sub directories to 777" You replied with by saying the Tobean should review the instructions and that "You will have to make sure all files and all folder and sub folder and all files inside those have the correct permissions." So in response to Tobean telling you that she or he had complied with step 5 of the preparations section of your instructions, you suggested that the solution was to follow thie instuction in step 5 of the preparations section. Can you see how that fails to be even slightly helpful? Do you see how disrespectful that is? Of course you didn't write the "F" word in there but it's the same level of disrespect. I'm sure that you didn't mean an insult. You're a busy person and I'm sure you just didn't read the question as deeply as you normally would. The only important question here is: what can Tobean (another user landing on this thread) do when faced with the "Directories Must Be Writable" error?
  2. 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.
×
×
  • Create New...