What about you Steve. See any problems with getting MU configuration locations right and allowing for uploading?

-Radio- said:

YES – /var/www/vhosts/planetgreencentral.com/problem-with-post-edit-buttonttpdocs/wp-content
YES – http://planetgreencentral.com/wp-content

Still coding with a Brick so:

This looks like how you would find out if you are in MU

and simply apend ‘/files/’ to both of those and they will opperate correctly as if in normal WP. WPMU handles the /blog.dir/number/ so you don’t have to do anything differently.

ok…

It looks like a blog can exist but if nothing has been uploaded by any other method (media uploader, etc.) creating the plugin's upload folders in /files/ can fail.

test if the /files/ directory exists, if not, then create the /files/ dir before creating the upload folders.

Steve and Paul:

Here is the proposal. This COULD be done for a 4.1 final release. Radio has said he can test on MU and (with one worrying exception) it shouldn't knock anything for standard WP sites.

1. A new constant – SF_IS_MU set to true or false
2. Two new constants that define the base storage locations for either WP or for MU – SF_STORE_DIR and SF_STORE_URL. These can be defined at the same time as the current WP_CONTENT_DIR and WP_CONTENT_URL. For standard WP these will be the same. For MU they will be extended with the '/blogs.dir/blogIDnumber/' path.
3. For all instances of $SFPATH in the code (about 45) replace WP_CONTENT_DIR and WP_CONTENT_URL with SF_STORE_DIR  and SF_STORE_URL.
4. Remove the restriction on uploading within MU.

The above should have zero effect on WP sites as all we are doing is replacing the current constant with a new one that has an identical value.

The one piece of grit in the vaseline is in sf-constants.php where we define the following for admin side uploading:

    define('SFUPLOADSMILEYS',    '/wp-content/'.$SFPATHS['smileys'].'/');
    define('SFUPLOADAVATARS',      '/wp-content/'.$SFPATHS['avatars'].'/');
    define('SFUPLOADRANKS',           '/wp-content/'.$SFPATHS['ranks'].'/');

simply because these are relative paths. Easy to get right – they just don't fit into the overall scheme in a standard fashion. Actually, of course, they are currently incorrect for MU users anyway. Could you confirm that Paul? Where do MU users create their 'smileys' and 'avatar' folders?

Big question…. can either of you guys see any holes I may have missed?

nothing jumps out, but frankly havent followed all those emails and this thread very closely since you were all over it…

obviously, we will have to do some heavy testing on our different wp configurations too (doc root, subdir, subdomain, etc)…

and no issues, but I think this should mean a beta 3 before gold/final release…

all spf custom folders are created (currently) in /wp-content/

in MU this makes them global folders across all sub-blogs. My suggestion for MU is that they get created in /wp-content/files/  as this will segregate them from other sub-blogs.

It is my BELIEF that MU will handle the /blogs.dir/ID/ portion. I state this as a belief, because as other plugins create /blogs.dir/ID/ folders, I can not find anywhere that they ever alter their path other than prepending /files/ to their final folder name, yet they work correctly under MU.

again, if you have a 'theory' you need tested, create a php code for me to run and I will report back.

Morning Paul

OK- I have committed the changes for this. Obviously I am totally unable to test this under MU but al appears to be well on standard WP. It mainly rests on the veracity of the codex and that one function call!

Any chance you can test this? Actually all locations (skins, icons, help etc) as well as configuration and uploading.

Are you able to grab the changes from SVN? Or export out a whole 4.1 B2 system? Or do you want me to email you the changed files? In case you can do it yourself, these are the files that have changed (11):

AH HA!

found something

This is the code to create the blogs.dir/ID/files/ folder if it does not exist:

BLOGUPLOADDIR appears to be a CONSTANT in MU.

using your previous test code as a base I retrieved this info:

To reply to #22 above.

if you could e-mail me with a 'patch' that I could upload over the existing files, I can use FTP to simply overwrite the existing installation on planetgreen.

My post, #23 above may alter your changes however.

My belief from post #21 is WRONG. wpmu does not AUTO MAGICALLY handle the blogs.dir info, but the new MU constant does provide a place to start creating the PATH of the uploads.

From your post #19:

SF_STORE_DIR should be defined under MU only as BLOGUPLOADDIR + foldername

SF_STORE_URL should be defined under MU only as WP_CONTENT_URL + '/files/' + foldername

I hope this makes sence.

yes it make sense but 3 things… I don't see how yoy arrive at this:

SF_STORE_URL should be defined under MU only as WP_CONTENT_URL + '/files/' + foldername

I thought we established yesterday the WP_CONTENT_URL ONLY defines the path up to the 'wp-content' folder.

And second – do you know how long this constanty BLOGUPLOADDIR has been in existence. I don't want to start doing version checking for MU.

Seems to me that of there s an BLOGUPLOADDIR then there should also be a BLOGUPLOADURL. Do you know if that is true?

did we lose something here?

Ok – I have sent you  a set of files. Thanks

Sent them to the email address you have registered here on the site…. Let me know if you need it sent to a different address.

Mr Papa said:did we lose something here?

I don't think so. Tink I may have hot the blockquote by mistake

okay,thats what I was referring to…  wondered if some text got filtered out…

Yellow Swordfish said:

yes it make sense but 3 things… I don't see how yoy arrive at this:

SF_STORE_URL should be defined under MU only as WP_CONTENT_URL + '/files/' + foldername

I thought we established yesterday the WP_CONTENT_URL ONLY defines the path up to the 'wp-content' folder.

And second – do you know how long this constanty BLOGUPLOADDIR has been in existence. I don't want to start doing version checking for MU.

Seems to me that of there s an BLOGUPLOADDIR then there should also be a BLOGUPLOADURL. Do you know if that is true?

correct, WP_CONTENT_URL in fact only goes to 'wp-content' if you add '/files/' a built in redirection in WPMU automagically sends you the contents of 'wp-content/blog.dir/ID/files/'

… you asked before if this is ALWAYS the case, and in fact it is editable by the SITE ADMIN on a per blog basis… I can not for the life of me immagine any Site Admin going blog to blog to edit both, this variable, and the auto redirect location variable…

apparently this is a legacy (pre 1.1) constant

I actually did check for the URL companion constant, and no, it does not exist in the syntax, did not do a search for other syntax, as the path changes from blog to blog… but the redirect means the url does not.