ok… the patch nuked skins and buttons settings

looking at the locations. if an item is default in plugins/simple-forum … we shouldn't add the blogs.dir path stuff… or you should, and copy the files out of the plugin/simple-forum dir… to wp-content/blogs.dir/ID/files/ … this would make custom settings a bit easier blog to blog… just thinking out loud…

Yep – that was pretty stupid of me wasn't it? There are two base locations wanted – for the stuff that we supply (icons, skins, help etc) and for the stuff the admin can specify (avatars, smileys, uploads etc)

But this then begs a new question and perhaps one that would have been worth asking first.

So – forget what we have done so far for a moment. With the new storage location screen in place, surely we do not actually have to default to the full path. We leave it exactly the same as it is with standard WP (i.e., '/wp-content/') and let the site admin fill in the rest where appropriate. It's up ti them.

– OR –

We just make it simple and ascribe the standard location to styles, hooks, pluggable and help and the extended MU location to avatars, smileys, badges, image/media/file uploads and custom icons. The site admin has to go off and make the necessary folders anyway (although we try at install time we are unikely to have permission to do so).

So that would mean a new install has these locations pre-defined but fully editable. An upgrade from previous version has to define them.

Now for the crunch. I would say we have just today to make up our minds or else we will endanger gettign this beast to final release. The changes I have already made means that to put things back alI need to do is delete an 'if' statement. What is proposed now is that we put the code into the Install routine. In other words the extended paths become part of the DATA not implied inb the CODE.

All in favour please say aye.

delete the if

4.1 beta is already fine work… this can wait a release as MU users aren't pounding on the doors, yet

Easily done but why waste the opportunity?

It is a real easy matter to turn it around the other way. Go back to making the 'base' /wp-content/ as it was before but adding the MU path into the default data paths during install. I should really have thought of this first. it forces nothing on MU users they can't change in the configuration panel but sets them up with better and more MU 'correct' paths for their storage.

ok… works for me… will try it out when you need it

I have made and committed the changes. Everything is now in the install routine – nothing in Upgrade as yet as the install needs to be tested to make sure I am on the right track.

Can you test this with an MU system – install a new SPF?

Paul: Any chance you an test a fresh/new install? If so do we need to sned you the code files or can you perform a straight export from svn?

if i ever get out of hospital, yes, I can test. But it's always better to send me a patch zip containing the changed files.

SVN is Evil

You really need the whole thing and the test has to be a complete and new install. SVN is pretty good at that – just using the export command.

Paul: Would you be in a position to test this for me now? All you need is a 4.1 system, a small edit to one file and then create a completely new (MU) install somewhere. What we need to check are storage locations are being correctly set (even if folders are not being created).

The bit of code to edit is in sf-control.php – quite near the top – where the following lines of code need to be uncommented:

Any chance you could try this and if good we can open it up in the 4.1.1 update.