Wedge

In your case, you'd use exactly the same process. The only time for using it yourself is if you run a local test server that doesn't have FTP or SFTP on it.

And while I understand your concern about it being two different processes, it really isn't, the actual install doesn't happen till you hit the enable button, so it really is automating the upload process that we're talking about here.

No more than SMF does: store the username, port and maybe the partial-path[1] in the database, and request the password once per session (and store that obfuscated in session)

1.	You know, where it presents /home/user/ as /

OK, so I've been trying to figure out how to cope with this. One of the biggest problems with SMF's environment is that it makes your files writable by everything, essentially. You have to make your site vulnerable on shared hosting in order to upload and install mods - even pure hooks ones.

In our case, there's no file edits at all. But there's still the upload problem: you have to write something to the relevant folder. Which means that folder has to be writable by the webserver.

So, I tried a different tact, what if through some process, we no longer required write access to that folder, but that we could delegate it off to something which did? Or, as I call it, you upload the plugin file, it goes into the system temp folder (where all uploaded files go), where it's unpacked.

Here's the trick: instead of uploading it into a physical folder or something like SMF does, we unpack it serially (going through the archive file by file), push the file to temp, then we send it via FTP from our script to the server. It's seemingly stupid but I see no reason why it won't work, other than the mechanics are a PITA.

Doing that means you don't have to make the folder writable or indeed do anything to it, essentially it's being uploaded to by you (and thus OWNED by you) just as if you uploaded it yourself. No changing permissions, no changing them back.


The caveat is that I would remove direct local filesystem support. This would make for a slight inconvenience on test forums/localhost where FTP isn't configured, because it would mean there would be no facility for uploading as SMF currently does. But the price paid in convenience is security: if you don't ever have direct filesystem support, there's no need to screw around with making things 777 (and hopefully that plague of bad advice will not follow us here), and it's not like you can't just unpack it and upload it yourself.

I have the uncomfortable feeling it would pretty much demand .zip support because the contents of /tmp are intentionally unstable and I'm not sure how comfortable I am with unpacking a .tar.gz in /tmp and expecting it all to be there after (as opposed to .zip which can be handled a file at a time)


So, thoughts? Concerns? Questions? Anything that didn't make sense and people would prefer I explained it in actual English?

Don't worry about it :) It's actually not very clear what it relates to, is it?

It'll be when it's ready but I'm increasingly getting a nagging feeling that it needs to perhaps be sooner rather than later if only because I'm finding it harder and harder to make more objective choices about things like this.

Semantics aren't really that important in themselves. What's more important is understanding what results. It is one thing to understand that 'show avatars = yes' is easier to understand than either 'don't show avatars = no' or 'hide avatars = no', and another thing to understand why. Semantics gives you the answer as to why, but you don't need to know why in order to make use of it ;)I don't like the idea of having tabs. Having more tabs indicates another level of hierarchy, as it is, there's already the tabs of the main menu, the admin menu, and the manage member options menu.

There is also the concept of chained actions, if you think about it. You might want to set the defaults when starting out, but it's also quite likely that later on you're going to want to reset the default and reset everyone to that default when you do change, much as you might do with themes. In that case, having the two together is sensible.

OK, here's an updated screenshot. Even just having the breaks visibly improves things to me.

I do also get the feeling to a point that this is one of the things that looks horrible but isn't so bad once you actually get using it.

Perhaps we should bench this one for now in UI terms (though not the wording changes, haha) and come back to it when Wedge is publicly accessible in some fashion so that you can actually try it out yourself and let me know how it feels to actually use - right now I'm probably the only person that's used this.

The semantics explain why it's easier to read the positive assertions ;)

Anyway, the first two of these are now done, and as we go forward hopefully we can keep things positive ;)

The admins might not, but I do. It's long bothered me that it never felt right, but it wasn't until this conversation I was able to understand *why*.

End of the day, it's something that's been brought to my attention through whatever means and I don't like it!

I've already changed show_no_signatures to show_signatures (yes, everywhere in the code, hell I even made what I think is a half way decent attempt to fix the French translation) (This took about 5 minutes, and had I just been bold enough to do it, I would have done it already and the argument would have been moot anyway :P)