Forum Replies Created

Viewing 13 replies - 1 through 13 (of 13 total)
  • O.K.- I appreciate your informing me of this temporary workaround, this should be helpful. Thanks!

    Any estimate, for when the next version of the plugin will be released? (I need to pass text strings to the snippet, and it is vital that the strings are passed exactly intact, with the spaces and the capitalizations preserved.) If this wasn’t the sort of thing that this feature was intended for, then is there any other way of doing this, at present? Thanks.

    Thread Starter CarynG

    (@caryng)

    How strange… all day yesterday it wasn’t working, but now today the slideshow images are back up on my site (and again, I’ve done nothing whatsoever). So I’ve marked this issue as “resolved”, and I do hope it stays that way. 🙂 (What’s disconcerting is not knowing the root of the matter, but I guess I’ll just hope for the best at this point.)

    Thread Starter CarynG

    (@caryng)

    Hi again. So an update to this plugin came out the other day, and after I installed the update this problem went away. So I’ve marked this issue as “resolved”- thanks.

    Thread Starter CarynG

    (@caryng)

    Thread Starter CarynG

    (@caryng)

    Hello again- I opted to go with your development version, and I just tried it out and I had no problems at all with it. So, I’ve just changed the status of this topic to “resolved”, and I also gave you a very well-deserved positive review here- http://wordpress.org/support/view/plugin-reviews/updraftplus

    Thanks again!! 🙂
    -Caryn

    Thread Starter CarynG

    (@caryng)

    SWEET!!! 🙂 Yes- that file name turned out to be the problem, because after I did exactly what you said, the restore completed successfully (with all the files that I had deleted from my themes directory, put back in place- yea!)

    So it’s possible that this has never come up before because most site titles aren’t as crazy as mine is (and it could also be that, in combination with running on an IIS server- perhaps Apache servers can handle creating directories with names like that. My experience so far with working with sites on IIS servers versus on Apache servers, is that I get confounded by these sorts of problems left & right with IIS…)

    So although I do now have a “work-around” for this, and it probably won’t come up very often in general with people using your plugin, I was wondering if you would perhaps consider making a new version, that truncates the site title in the file name after so many characters, in the event of of the site title being so long? (And maybe strip out “non-standard” characters, too- it’s also a possibility that it wasn’t the length of the site title, but rather that it had characters in it like “|” and “+” which also happens to be the case with my title. When I performed your test, I replaced the entire site title with just the word “test”- because I was so eager to see it finally work so I wasn’t up for playing around with all the different possibilities…)

    Well thanks again, for all your help in getting this resolved!

    Thread Starter CarynG

    (@caryng)

    O.K.- I’ve just e-mailed that file to you. I also took a look at the contents of this zip file myself, and it looks fine to me- it does seem to have all of my site’s theme files. But the file name is rather long… like over 120 characters (I see that it’s including the site’s title in the file name, and in the case of my site, the title happens to be a bit of a mouthful.) 🙂 So, do you think it would be worth a shot for me to alter the title of the site, to make it something a lot shorter (since I’m doing all this on a test site, there’s no real consequence of doing that), and then I can try making another backup and see if the restore works when using a backup that has a shorter file name?

    Thread Starter CarynG

    (@caryng)

    Yes, this was a great test to try. Here’s what the output of z.php was:

    bool(false) bool(true)

    But that first “false” I believe is because the upgrade directory already existed. The “testing” subdirectory had not been there before though, but after I ran z.php, I saw that this subdirectory had been successfully created on the server (and hence the “true” in the output, for the second variable). And then right after I ran z.php, I went to try to do the restore again (to check to see if that problem was still there), and I am still getting the “Could not create directory” error message unfortunately. So, if you’re absolutely certain that the UD plugin is not trying to create any directories anywhere else but under wp-content/upgrade, then perhaps your guess may be right, that my server just doesn’t like the given name of the new directory that it’s trying to create?

    Thread Starter CarynG

    (@caryng)

    Hi again. David, hartmutnz, just to clarify: my site is actually fine (but thanks for the concern, very nice of you. 🙂 ) So the deal is, I’m in the process of developing a new site, and “get backup mechanism for it” was just one of the items on my long “to do” checklist… So I created a test site on the same server, installed the UD plugin on the test site, did a backup, and then I went and deleted some tables from the WordPress database, and I deleted a bunch of files from my test site’s theme directory, and then I did the restore to test to see if it made everything whole again like it’s supposed to, and the database actually got restored just fine, but I got that error when it attempted to restore the files. So fortunately I wouldn’t say this is a crisis situation (so David, yes- I can wait for your new UD version which may address this, hopefully), but it was still a bummer to run into this problem (I was expecting this whole exercise to be very routine and simple, so I can move right along to finishing the actual development of the site, but alas no such luck for me.) Well thanks again for your kind help, and when your new UD version is ready, please let me know.

    Thread Starter CarynG

    (@caryng)

    Hi. I was just trying to do the restore by clicking on the big blue “Restore” button, that’s at the top of the UpdraftPlus page in the WordPress back-end of my site.

    Thread Starter CarynG

    (@caryng)

    David, thanks again for answering. Yes, the server is using IIS. I don’t think it’s that the write permission isn’t set for the particular user that write permission needs to be set for (the PHP user)- I followed the instructions given on this here page that I found:

    http://serverfault.com/questions/105420/which-user-does-php-iis6-use-to-read-write-files

    and I uploaded that test.php file to get the PHP username from the output of phpinfo(), and this username does have write permissions for both the wp-content and wp-content/upgrade directories. So could you maybe check your code to see what other directories it may be trying to create, in the process of trying to restore files from the backup- maybe it’s actually some other directory that I need to give the write permission to for the PHP user? Or maybe I can just manually create that directory myself? (Yea, aren’t problems of this nature the most aggravating? And these are the problems I always seem to get!) 🙂 Thanks again so very much- I really want to use your backup plugin for my site because it seems like the best one out there (and I wonder if I try to use some other backup plugin, that I’d just run into the same problem with any other plugin I try, so I think I really just need to solve this fundamental issue with the write permissions).

    Thread Starter CarynG

    (@caryng)

    Thank you so much for your prompt reply, David. Well, I checked and those 2 directories do have write permissions assigned, as far as I can tell (from checking the “Securities” tab of the “Properties” dialog, for those directories… is there perhaps anything more specific that you can recommend, if I’m not on the right track here?)

Viewing 13 replies - 1 through 13 (of 13 total)