Forum Replies Created

Viewing 15 replies - 16 through 30 (of 114 total)
  • Plugin Author TerraFrost

    (@terrafrost)

    0.7.0 has been released. The modal dialog is to restrictive imho and useful features had to be removed to accommodate it. In particular, key previewing.

    Also, in looking at the code, the old phpseclib_request_filesystem_credentials function had a fallback for browsers that didn’t support HTML5’s reading of the key whereas the new one didn’t.

    Plugin Author TerraFrost

    (@terrafrost)

    The latest version in trunk adds some expanded error messages.

    Also, if you want some fast diagnosing give me SFTP access. Email the credentials to terrafrost@php.net.

    That said, one issue that still needs to be fixed… so I removed the textarea to save on screen real estate but the RSA key is still being cached there. What this means is that you can’t see what the RSA key is. You can’t preview it. So I think I need to bring back the textarea, maybe as a modal or some such.

    Plugin Author TerraFrost

    (@terrafrost)

    First, I think you should probably create a new topic instead of posting in this one.

    Not sure how to revert back to the old one.

    SFTP in with a regular SFTP client?

    Can you please fix the “Private Key Incorrect” issue soon please?

    You’re assuming that there actually is anything I can do to fix it. If you really are using the incorrect private key there’s no amount of code changes that I can make that’ll make it work.

    If it’s an issue with you using selinux… well again there’s not a whole heck of a lot I can do. I might be able to make the plugin present a warning if you’re using selinux but if fsockopen() can’t connect fsockopen() can’t connect and I can’t change that in PHP.

    Everything is grayed out on that screen so I couldn’t upload a new key even if I had one.

    FWIW, a lot of this code is copy / pasted from WordPress’s built-in functionality. phpseclib_request_filesystem_credentials_modal is pretty much copy / pasted from wp-admin/includes/file.php. There are some slight differences but those differences are very slight.

    Anyway, quoting from the function:

    <input name="hostname" type="text" id="hostname" aria-describedby="request-filesystem-credentials-desc" class="code" placeholder="<?php esc_attr_e( 'example: www.wordpress.org' ) ?>" value="<?php echo esc_attr($hostname); if ( !empty($port) ) echo ":$port"; ?>"<?php disabled( defined('FTP_HOST') ); ?> />

    <td><input name="username" type="text" id="username" value="<?php echo esc_attr($username) ?>"<?php disabled( defined('FTP_USER') ); ?> size="40" /></td>

    <td><input name="password" type="password" id="password" value="<?php if ( defined('FTP_PASS') ) echo '*****'; ?>"<?php disabled( defined('FTP_PASS') ); ?> size="40" /></td>

    The only time a field is disabled is if you’ve defined an FTP_* constant corresponding to that field. Presumably you’d do these definitions in wp-config.php altho I guess technically they could be done anywhere. So check that.

    Plugin Author TerraFrost

    (@terrafrost)

    Can you confirm that this plugin does only use SFTP, and not full SSH?

    SFTP typically requires SSH but in a jail shelled environment you might not be able to do any shell commands.

    That said, the plugin does currently do some SSH stuff for stuff like chgrp. It’s doing this because the built-in WordPress plugin does it (or did it when I initially implemented this plugin) and because, at the time of this plugins initial implementation, chgrp wasn’t something that phpseclib would let you do via SFTP (altho that is now no longer the case).

    Practically speaking, tho, idk that WordPress does chgrp a lot if at all.

    I would like to suggest that you add more documentation than simply “install and go”, since this plugin relies on the upgrade, plugins and possibly other folders being writeable by the SFTP user, and I had to discover this by the trial and error method, which shouldn’t be necessary.

    I think what’d probably be better are run-time checks. eg. if you try to install and the directory isn’t writable an error appears.

    Additionally, documenting how this plugin does nothing if WordPress decides that direct file updating is possible, whether that works or not, and that you can force this plugin to be used by setting the FS_METHOD variable to “ssh2”. I would have assumed that would have forced the built-in SSH2 support to take over. It’s just not clear.

    Under what circumstances does direct file updating not work? I haven’t spent a great deal of time looking at how they implemented that.

    I’m also not sure off hand how it works with FS_METHOD. Probably just the same way WordPress’s built-in functionality works. This plugin is /mostly/ a copy / paste of that element of Wordpres’s built-in functionality.

    Plugin Author TerraFrost

    (@terrafrost)

    Only error I see is ” PHP Notice: Undefined variable: allow_relaxed_file_ownership in /home/html/wp-content/plugins/ssh-sftp-updater-support/sftp.php on line 37″

    I’m pretty darned sure that that issue was fixed in 0.6.1. ie. the version you should be running if you are indeed running the latest version.

    Regardless, what version of WordPress are you using? Can you post a copy of your sftp.php? Post it on pastebin.com and post a link here.

    As for the “Private Key Incorrect”… two possibilities I can think of off hand.

    1. The private key really is incorrect.
    2. You’re using selinux

    idk if the logging techniques I used to debug previous versions of WordPress will work with 4.2. If not I’ll need to come up with new ones. I need to investigate that and how to come up with a reliable selinux test.

    I have a busy next few days but I’ll try to squeeze it in.

    Plugin Author TerraFrost

    (@terrafrost)

    The built-in functionality requires libssh2 be installed and a great many hosts do not. It’s not included by default with PHP either so even if you’re running your own server it’s just one extra step you need to take if you ever need to rebuild the server.

    This plugin, in contrast, uses phpseclib to remove that dependency. This plugin will pretty much work on any host.

    Also, the built-in functionality requires the private and public key both live on the local file system. With this plugin the key never touches the filesystem. Even if you upload it no temp file is created since all uploading with this plugin does is to copy the key contents to a hidden input field (hidden as of 4.2 since 4.2 introduced a modal with limited screen real estate). And you don’t need the public key either – just the private key. The public key can be extracted from the private key anyway.

    More info:

    http://phpseclib.sourceforge.net/ssh/compare.html

    Plugin Author TerraFrost

    (@terrafrost)

    Plugin Author TerraFrost

    (@terrafrost)

    The biggest problem with this is screen real estate. Especially when updating already installed plugins. As of WordPress 4.2 a modal is used for that and due to the lack of screen real estate I already had to remove the field where keys could be copy / pasted (now you have to simply upload the key, which through HTML5 JS puts it into a hidden textfield)

    Plugin Author TerraFrost

    (@terrafrost)

    Plugin Author TerraFrost

    (@terrafrost)

    @gr0g – I’ll try to look into this this week.

    I have not seen this error before but the server I develop this on probably does not have error_reporting set in a way that’ll make this error display.

    As for why I haven’t addressed this earlier… this plugin isn’t my main focus in life. I only have so much time in the day and I have to prioritize how I spend it and sadly this plugin gets prioritized considerably farther down than a lot of other stuff. And unless this plugin starts making me a ton of money I don’t really see that changing.

    I mean, I’m checking up on support topics right now but I’ll stop at some point. I am not going to let this plugin take away from other activities that I either enjoy more or that pay the bills. At least not on a long term basis.

    Anyway, that’s why it hasn’t been addressed earlier. None-the-less, now that I am aware of this issue, I’ll try to address it this week as time permits.

    Thank you for your patience.

    Plugin Author TerraFrost

    (@terrafrost)

    @ziggy43 – try the 0.6.1 release.

    Plugin Author TerraFrost

    (@terrafrost)

    Try the 0.6.1 release.

    Plugin Author TerraFrost

    (@terrafrost)

    I just downloaded WordPress 3.9 and installed 0.6 of this plugin and was able to both install other plugins and update to WordPress 4.2.2 with this plugin. See the screenshots below:

    http://i.stack.imgur.com/JQtSM.png
    http://i.stack.imgur.com/9qdmA.png

    So I’m not able to recreate the loop you describe in your post when upgrading WordPress. Maybe you’re upgrading from a different version?

    That said, deleting plugins on 4.2.2 does seem to be an issue with v0.6 of this plugin. I am looking into it now. Thanks for the heads up!

    Plugin Author TerraFrost

    (@terrafrost)

    Plugin Author TerraFrost

    (@terrafrost)

    Just released a new version – lmk if it works for you!

Viewing 15 replies - 16 through 30 (of 114 total)