I agree with both positions, but I also believe that human stupidity should never be underestimated.

Already SPF has three folders located outside of the wp-contents core folder for smiles, avatars and uploads, and yet the majority of issues with those items covers the fact that users don't know where they go, or what they need by way of permissions, in order to opperate.

I do feel that the SPF manual upload process is a beast, holding in one or two sub folders, more files than the whole of WP or WPMU.

At one point I attempted to argue that SPF should be broken into multiple plugins, each focusing on individual functions of the forums.

This approach would be a third option to the two that you pose, as

1. It makes the plugin core smaller.
2. It makes upgrading safer and could easily be automated.

AND:

1. It makes that initial installation much easier.
2. It doesn't confuse the majority who don't have a clue.

Just my 2p.

-Radio-

lol, that hackers discussion got a bit wild…  will comment when I have more time…

I really dislike this idea, but think that we MUST do it…

we have chosen wp as our engine and we must accept the warts with the good…  like it or not, the core developers (and thus the code base) really dont want any “user” files in the plugins directory.  they believe only plugin files belong in there.  and they dont believe even css files are plugin files.  while I may not agree with it, if its not the end of the world, I am for doing it the wp way. we cant be critical of others not doing it the wp way if we arent willing to do it ourselves. this will give us an ability to add an auto installer much easeir I belive.

If updating a new plug is really as simple as deleting the old and uploading the new, as the plugin installer does, we should not keep and static data that we want left around in there.  I would have preferred some sort of filter or something to indicate files to keep or such as discussed on hackers and wp trac, but thats not going to happen.

this will cause folks to get lost and give us a bunch more support tickets, but I think we should bite the bullet and do it.

If we do this, I would suggest we create a single spf folder under wp-content (or maybe wp-content/uploads) for this user data and then put everything under there.

Radio said:

At one point I attempted to argue that SPF should be broken into multiple plugins, each focusing on individual functions of the forums.

I see your point but I would have absolutely no idea how to go about it. Well – that's not quite true as bacically it would require starting again with a blank php file and recoding the lot! Now this is something I would actually like to do but my hair is quite grey enough as it is.

Mr Papa said:

I really dislike this idea, but think that we MUST do it…

That is more or less how I feel about it. And while I suspect that the Mullenweg may well end up vetoing the call for a standard 'plugin data' location under 'wp-content' it is, actually, a call that just might gain some traction. If it gets thrown out as a core development then I can well see some of the more prominent plugin authors may just take the matter into their own hands.

If we did this, then 100% it would have to be in a single folder. But – here is another thought: We could actually be quite smart here and leave the user to decide. Those with large, sophisticated and/or customised forums would probably welcome the opportunity to better protect their files. Those with simple sites could leave it all where it is. As long as we have clear information on where things are there is actually no need to force anything.

We could do this wth a second, small and simple plugin, that would act as a configuration tool and allow users to optionally provide path informatiopn for all of the stuff originally listed above. This would be very easy to set up and for us to use and would be entirely optional but would allow those that need it to take advantage of the notion.

Paul: How would this play with WPMU ?

I like the configuration plugin idea, it will play well with wpmu if admin can assign the location of the files.

this config plugin would have to account for the ftp location and the http location being different locations.

MrPapa said:

If we do this, I would suggest we create a single spf folder under wp-content (or maybe wp-content/uploads) for this user data and then put everything under there.

WPMU handles uploads a slight bit differently. Uploads are placed in a sub-sub-directory specificly wp-content/blogs.dir/{blog_ID}/files/ (so for the main blog it's wp-content/blogs.dir/1/files/ )

wpmu however, uses .htaccess to map those directories. Under http accessing those uploads would be calling http:/ / sub-blog.url/wp-content/files/

User modifiable documents could be stored in the blogs.dir, but they are accessed by http in the mapped location.

plugin required files – skins/icons/etc. which would have to be globally accessable on all blogs, could easily be placed in their own folder under wp-content/… if a particular blog owner wants a custom skin/icon-set/etc. this plugin idea would allow the sub-blog owner to upload their own(media upload?), and point to it with the config plugin.

—

although you have done an excellent job supporting wpmu, better even than automatic's bbPress or the wpmudev's own 'premium' forum plugin, I feel that wpmu code is becoming a heavy issue for you.

I do have a suggestion along the lines of this discussion; use more plugable functions in your code, and remove wpmu specific code, to a wpmu config type plugin. No specific user interface would be needed, simply having it active plugs the functions necessary for wpmu.

such a plugin should not require 'Installation', but should be smart enough not trigger errors if SPF it's self is not activated yet.

If this wpmu config plugin could be kept down to one php file, that file could be placed in wp-content/mu-plugins where it is instantly activated across all blogs in the wpmu setup. This is normal for wpmu specific plugins.

in this case, SPF could develop for WP much faster, with wpmu specific changes effecting one file, in one location, simply plugging/patching spf routines, with wpmu routines if needed.

Actually Paul I don't really think it is a burden as such. It is just a struggle to get a handle on MU as it seems brain damaged in so many ways. Surely once we've got it then it should just tick along nicely….

But – leaving aside your question of a separate MU 'override' plugin for a moment and going back to the original question I am very tired and not at my best this evening which could explain why I do not quite understand the comment:

this config plugin would have to account for the ftp location and the http location being different locations.

I am not sure why I should be concerned about ftp locations and what exactly IS an ftp location? I was just talking about storage locations and paths so we can find the stuff…?

the battle on hackers continues…  three camps…  the dev side who said say somewhere/anywhere under wp-content as long as its not in plugins…   and then two plugin author camps… one wants a plugin-data under wp-content and one who wants a plugins-data under plugins…

sheesh…  I like your idea of andy and letting the user decide, but we might want to make sure it stays outside the plugins directory just to be safe…

and have to laugh about that schinkel character…  I just dont get him…

especially the whining about the plugin updater having issue with his .svn directories…  sorry, but wtf are you using the plugin update for if you have it checked out with svn??????  pick one way of updating and move on…

btw, love how DD32 put him in his place (typical response)… hate to see him (DD32) leave hackers if he really does…  contributes nice stuff..

OK – I have raised a ticket for this for 4.1

First draft of the 'configuration' panel is in place. This is under a separate 'Manage Configuration' menu option.

I strongly feel that we should not impose an alternative storage location/structure. AT the moment I have coded it for a user to create their own. If this means it will only ever be used by those with skill and knowledge so be it.

One good reason for this is, of course, when SPF gets installed we have no guarantee that we can even create a folder down in wp-content, yet alone copy stuff into it. The avatars and smileys copying meets with mixed success and seems to never allow us to remove the originals.

But as always, thoughts and suggestions welcome.

I will almost certainly move the 'optimisation' panel from Manage Admins to this new location.

I have a suggestion. When either an upgrade or install takes place, after the process finishes we redirect to the Manage Options panel. I propose we change this to the new configuration panel with some big, bold text to show what may have gone wrong and also to give pointers on how to use it of they choose to.

Steve: I think your problem with tinyBrowser is simply that the folders did not get created on the upgrade – taking them to configuration will at least identify quickly what may have not worked so they can put it right. Well. OK. SOME of them can put it right! The rest will just post  a support question but that happens now!

(It is probably not JUST because the base folders did not get created that tinyBrowser is also unable to create them although that is probably lin ked = if folders can not get created via code then they can't – it is that simple. But it is exacerbated  by the fact that the base folder (say, 'forum-media-uploads') then has a second folder appended ('/mr-papa') and I am guessing that it can not create that because the parent is not there.)

well, the parent is there and always has been there…  the image upload directory from the pre-upgrade stored in the options table (?) did not get copied over to the new configuration table options at upgrade time…  I did manually enter it into the image upload field and the tiny browser started working, but still complained it couldnt create the mr-papa directory…  I suspect something with windows…

In fact, I use the same base directory for image, media and other files…  all fail for same reason of creating mr-papa directory within that directory…  I suspect most users will want the per user directory and our challenge is going to be gracefull degradation/failure when the directory cannot be created…  admins wont want to be manually creating directories for many users…  we will need good help on this…  I do like where its heading though!

I have no issue with redirecting to configuration instead of options…

It creates them with no problem on my local setup. Not Windows of course and not WAMP/LAMP either.

This is also now a part of 4.1. Am pinning this topic for any firther discussion and testing problems.