upload directory problem

shandley

New Member
Using 1.05
Joomla 1.0.13

I am running two joomla sites on the same domain in different directories. I am trying to upload files from a form in directory A and then pulling the data and file paths in a fabrik table in directory B. Everything seems to work except the path on directory B is goofed up. I broke it down a little more below to make sure you understand the issue.

I have a form that uploads one image and 2 files.

They all are uploading correctly. The posting in the database is the entire URL i.e. http://www.site.com/directory/attachments/filename.doc

I am trying to pull these files up in a different joomla site on the same domain in a different directory.

My connections work fine and it pulls the data, but the links to the files and image looks like http://www.site.com/directory/http://www.site.com/directory/attachments/filename.doc

Notice the repeat of the http:// part. I have tried various combinations of file paths and haven't been able to sort it out.

I feel like the file paths FOR THE ELEMENTS in the admin sections of fabrik in directoy A should be one thing, and in directory B something else. Or maybe they should match eachother.

Thank you for the help.
 
I think you've just stepped into a big pile of poo.

For unknown reasons lost in the mists of time, the upload element stores the full URL, with $mosConfig_live_site (your root Joomla URL) prefixed. When we display the link, we check to see if it starts with $mosConfig_live_site, and if not we prepend it.

This has rather predictable dire consequences if (say) you change you $mosConfig_live_site.

I've been fretting about this for some time. Yours is just one case where this breaks things, and it's been a background pain in the support backside for some time.

The only way I can think of to fix it is to have a one-time function which goes through all your upload elements in the actual database tables, and strips the live site prefix off. And modify the save/display code so we don't prepend when we write, only when we read.

We already do this for several other issues, where a one time routine runs the first time after you upgrade and hit a backend Fabrik page and pokes around with your data. It's just a stressful thing to do, 'cos if you mess up ... bang goes everyones data, LOL!

I'll raise a ticket associated with this thread to get it on the official To Do list, but I can't guarrantee when I'll have time to do it.

Short term, your only solution would be to add a custom line of code to one of the Fabrik PHP files to do a replacement when the data is read. If you don't mind doing this, let me know and I'll tell ya what to put where.

-- hugh


-- hugh
 
Fix for upload directory problem

I am just getting this setup so fixing the current database isn't a problem for me. I'm more concerned about setting it up to record a relative path or something like that.

I'm comfortable making any changes you suggest.

Thanks again.
 
Hello guys,

just to add a bit on this....With file uploads and in general any kind of upload, i think its not safe to have them uploaded under the www directory. You see some people cant just get their heads around the "permissions" thing (or maybe its a bad hosting provider thing) and they just set them to 777 for the file uploads (ignoring the fact that its the php actually uploading it and not the web site visitors as per se).

As a rule of thumb i have always set my upload directories to a path above my www directory. So here are a couple of screenshots of my file upload settings showing the same problem when reading the file back (the $mosConfig_live_site being appended to it)....

I am not sure why it was decided that this would be automatically appended to the start of the upload dir. I guess it was because some users may have difficulties working out the full path on their host...

I would suggest the following changes (without needing to change the element "file upload" form).

In the database keep only the user data entered in the path field.

Then depending on this user defined path:

Option 1

[setfullpath]../../../uploads

During form view Fabrik will work out the absolute path.

Option 2

/uploads or ../uploads (the "../" occurences will be ignored as they are ignored at present)

During form view Fabrik will work out the relative path (with the site url prepended).

In this way moving databases, hosts and sites will have no negative effect on the uploads as long as you replicate the same directory structure (the upload dir).

What do you think? I reckon this can be a very quick fix for Fabrik so that it becomes part of next revision...
 

Attachments

  • fileuploadsettings01.JPG
    fileuploadsettings01.JPG
    90.8 KB · Views: 275
  • fileuploadsettings02.JPG
    fileuploadsettings02.JPG
    57.4 KB · Views: 270
Yeah, that's pretty much the plan.

The "hard" part is upgrading all existing data people may have, to remove the $mosConfig_live_site. It's not that hard, just has to be rigorously tested, to make sure we don't blow anyway anybody's data.

I've started working on this.

-- hugh
 
Yeah, that's pretty much the plan.

The "hard" part is upgrading all existing data people may have, to remove the $mosConfig_live_site. It's not that hard, just has to be rigorously tested, to make sure we don't blow anyway anybody's data.

I've started working on this.

-- hugh


Wow, you are indeed restless !

I would think that any existing data will not be affected according to this:


Solution 1?
[ modification in view form]

Case 1: If mosConfigSite already in DB->"path record" then display it as is and finish.

Case 3: (case of mosConfigSite not in DB->"path record"). If no manual override prefix exists in DB->"path record" then add mosConfigSite and show updated Link else strip the
manual override prefix and use the rest of the string to work out the absolute Server path.


Solution 2?
Mmm, on second thoughts maybe this has some problems when people try to do joins etc...

In view of this, maybe the best option would be to force the user to enter the full path or the full url. So for a typical user he would either have to enter

C:\uploads

or

http://www.mywebsite.com/uploads

Solution 3?

Another way of making it more flexible would be to store the main path in a separate configuration field (component configuration) so that when moving servers it will need a single change in the configuration? And as for joins etc, they will have to manually append that configuration field?

Ah well...its too late over here...i think i am talking non sense....But our thoughts are with you !!!
 
Well the problem with approach 1) is ... what if you want to move servers, with lots of existing upload data. Or as the original poster is doing, trying to access them from a different instance of Joomla with a different live site path. We have no way of knowing what the old live site path was, so we can't do any kind of substitution.

I've spent the last 6 months off and on thinking about the best way to approach this, and the only total cure I can think of that solves both legacy and future issues is to massage existing data to get rid of the live site prefix.

I'm even thinking we don't need to prepend the path info (the "Upload Directory" set on the element), just any "subfolder selection" (if applicable) and the filename. But I just spoke to Rob about that, he wants to include the upload dir, for cases where people change it on the element, but still want old uploads to work.

Anyway ... looks like we've made the decisions, so I'll have this fixed this week some time.

-- hugh
 
Anyway ... looks like we've made the decisions, so I'll have this fixed this week some time.

-- hugh


Hi Hugh,

i agree. And to be honest i think you and Rob err...i mean the Fabrik team needs to re-evaluate the way ahead...What i mean is that its more important to get Fabrik 2.0 stable rather than perfecting 1.6. Of course all these posts contribute to the 2.0 development but they shouldnt really take much of your time....

I quote smt you said in previous posts "if it aint broken dont try to fix it"

and also Fabrik 1.6 is what it is with its strengths and limitations. Lets all look ahead on the 2.0 dawn :)

Many thanks !
 
We've already cut back new feature development on 1.x to a bare minimum, and only fix or improve things we think have a substantial impact. The only reason I'm doing this one is because it has raised its ugly head in about a dozen support issues over the last few months.

There's a couple of other tweaks and improvements slated for 1.0.7, but 1.0.x is already effectively "feature frozen", no new features, just bug fixes and improvements on existing features. 90% of our development effort is going into 2.0. Rob is already pretty much 100% focused on 2.0 - he only touches 1.0.x when there's some deeply arcane issue I have to call him in on.

-- hugh
 
Let me see if I can ask for a fix that is specific to my situation. I am pretty sure it is quick.

I have 2 fabrikar sites running. One in Directory A one in Directory B. The reason is for security reasons. It was quicker and easier than changing Site B.

When I'm on fabrikar site A, I file out a form, upload an image and some files and it posts to the DB for site A.

When I am on site B I am showing a Table and a detail page that pulls from the DB on Site A. The table page and detail page adds the http://www.sitename.com/directoryB to the file location which already has the http://www.sitename.com/directoryA so it looks double.

I would assume that somewhere in the table php page there is some function that adds the $mos_config_live in front of the db result for the filename.

On my fabrikar site A, I don't want it. I just want it to show the db result for the file location.

Please let me know what I can replace, delete or edit for this situation. If you just tell me the page to edit, I might be able to hack it up.

Thanks.
 
The form element code is in fabrik.html.php, around line 953 in the drawFileUpload() function.

The table code is in fabrik_table.class.php, around line 4022, in replaceDataWithIcons().

Should be fairly obvious which lines you need to comment out.

-- hugh
 
Hi huge,

can you please point me in the direction of the code that is used on the upload and save of the file name. I think that if we strip out the mosconfig_live_site out of the upload so that you get just a bare filename saved to the database. This should fix the problem. At the moment if I save the file I get the mosconfig_live_site saved in the database. This is also a bad idea as it means that if I move my site this is then incorrect.

If I change my database entry so that is is just the bare file name this works like a treat.
 
Around line 3122 in fabrik.class.php, in the _uploadIndividualFile() function:

PHP:
                // $$$ hugh - WHY do we prepend $mosConfig_live_site?  Why not just save it minus
                // the absolute_path?  Storing the live site path in the db causes all kinds of problems.
                if (!$groupRepeat) {
                    $this->_form->_data[$elName] = str_replace( $mosConfig_absolute_path, $mosConfig_live_site, $dosFreeDestFile );
                } else {
                    $this->_form->_data[$elName][$c] = str_replace( $mosConfig_absolute_path, $mosConfig_live_site, $dosFreeDestFile );
                }

Making those str_replace()'s be str_replace($mosConfig_absolute_path, '', $dosFreeDestFile) should do it.

-- hugh
 
I removed them and we are a little closer only it still records the path to the file.

we went from this being recorded into the database
"http://is.aut.ac.nzrequest_document_attachments/ImprovementRequest.doc"

to this
"request_document_attachments/ImprovementRequest.doc"

All we need to do is work out how not to record the first part in the upload.

Any ideas
 
Ok I figured it out.

I changed the lines to:

if (!$groupRepeat) {
$this->_form->_data[$elName] = str_replace( $mosConfig_absolute_path, '', $myFileName );
} else {
$this->_form->_data[$elName][$c] = str_replace( $mosConfig_absolute_path, '', $myFileName );

and its now working like a treat.

I don't know if this is the fix to your bug or that I might have broken something else all I know it works :O)
 
Ah, in a previous post you had said you just wanted to strip mosConfig_live_site out of the path, so that's what I showed ya.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top