@Otto,<br><br>WordPress writes data to theme files via the Appearance => Editor admin panel, without requiring FTP credentials. It only requires that the file being edited has '666' permissions, which I assume the user has to configure manually. The Editor panel will prompt a user to enable write permissions, and in many cases, the user will neglect to reset the file's permissions after they're done editing it. I'm curious to know how this scenario is different from the one you've explained. In other words, it seems to me that themes are being rejected for vulnerabilities that are already present in WP core. Can you please clarify this and/or explain how these scenarios are different?<br>
<br>Thanks.<br>-Darren<br><br><br><br><div class="gmail_quote">On Fri, Jun 24, 2011 at 4:57 PM, Otto <span dir="ltr"><<a href="mailto:otto@ottodestruct.com">otto@ottodestruct.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Jun 24, 2011 at 4:44 PM, Philip M. Hofer (Frumph)<br>
<<a href="mailto:philip@frumph.net">philip@frumph.net</a>> wrote:<br>
> I got around fopen by using file() instead and imploding it (thanks otto and<br>
> pross for the idea)<br>
<br>
</div>That only helps for reading files, not for writing them.<br>
<br>
And while I didn't go into it in my WP_Filesystem tutorial, there is a<br>
slightly alternative way to not have to display that form. It's not<br>
the safest of things, but it's reasonable if you want to present the<br>
user with as little difficulties as possible.<br>
<div class="im"><br>
<a href="http://ottopress.com/2011/tutorial-using-the-wp_filesystem/" target="_blank">http://ottopress.com/2011/tutorial-using-the-wp_filesystem/</a><br>
<br>
</div>If you read the tutorial, you can see where it is doing<br>
request_filesystem_credentials() call. If you delve into that<br>
function, you can see that it does its tests and such, but what it's<br>
really looking for here when it can't do direct calls and is forced to<br>
fall back to the FTP methods is $_POST['hostname'],<br>
$_POST['username'], and $_POST['password'].<br>
<br>
So if you don't want your user to see the separate FTP settings screen<br>
every time, then you can do something like this.<br>
<br>
// first, ignore this if we can write files with the "direct" method,<br>
which needs no credentials<br>
if ('direct' != get_filesystem_method(array(), false) ) {<br>
// display hostname, username, and password inputs on my form..<br>
// as long as they use those names and the form is a POST form,<br>
// the subsequent call to request_filesystem_credentials will use<br>
// them and not display an extra form to the user<br>
}<br>
<br>
That lets you sort of nicely integrate the credentials form into your own pages.<br>
<br>
If you wanted, you could even ask the user once, then store them in<br>
the database, and put them back onto the form in hidden inputs. I do<br>
not recommend this for security reasons, but it would work. The<br>
problem is that you have to store the credentials, including the<br>
password, in the database for this approach.<br>
<br>
You still have to detect the case when the given credentials are<br>
wrong, so the $form_fields option should be filled in properly and the<br>
if ( ! WP_Filesystem($creds) ) check still needs to be made, and the<br>
error in credentials case handled properly by displaying your form<br>
again to the user, but this method solves some theme devs objections<br>
to using the WP_Filesystem.<br>
<div><div></div><div class="h5"><br>
-Otto<br>
_______________________________________________<br>
theme-reviewers mailing list<br>
<a href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a><br>
<a href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers" target="_blank">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a><br>
</div></div></blockquote></div><br>