Jump to content

What does it mean "destinationPath is empty or does not exist (upload_file)"?

Nico Knoll

By Nico Knoll,
in General Support

 Share

Recommended Posts

Nico Knoll Hero Member

Nico Knoll

Posted
Posted

Hi,

I'm always getting an error if I'm save changes on a page with the field "upload_file" which has the type "file".

The error says:

destinationPath is empty or does not exist (upload_file)

What does it mean and how can I resolve it?

P.S.: Above the "choose file"-button is this text in red: "destinationPath is empty or does not exist"

Greets,

Nico

Link to comment
Share on other sites
Nico Knoll Hero Member

Nico Knoll

Posted
  • Author
Posted

I guess it's since I moved my local project to an online server... I imported the whole database and copied all of the data. And I changed a bit in my .htaccess file not to get an Error 500. It looks like this right now:

ErrorDocument 404 /index.php

<Files favicon.ico>
  ErrorDocument 404 "The requested file favicon.ico was not found.
</Files>

<Files robots.txt>
  ErrorDocument 404 "The requested file robots.txt was not found.
</Files>

<FilesMatch "\.(inc|info|module|sh|sql)$|^(\..*)$">
  Order allow,deny
</FilesMatch>

DirectoryIndex index.php index.html index.htm
<IfModule mod_rewrite.c>

  RewriteEngine On

  SetEnv HTTP_MOD_REWRITE On

  RewriteRule "(^|/)\." - [F]

  RewriteCond %{REQUEST_URI} (^|/)\.htaccess$ [NC,OR]
  RewriteCond %{REQUEST_URI} (^|/)site/assets/(cache|logs|backups|sessions|config|install)($|/.*$) [OR]
  RewriteCond %{REQUEST_URI} (^|/)site/install($|/.*$) [OR]
  RewriteCond %{REQUEST_URI} (^|/)site/config\.php$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)(wire|site)/templates-admin($|/|/.*\.(php|html?|tpl|inc))$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)site/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)site/assets($|/|/.*\.php)$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)wire/(core|modules)/.*\.(php|inc|tpl|module)$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)site/modules/.*\.(php|inc|tpl|module)$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)(COPYRIGHT|INSTALL|README|htaccess)\.txt$ [OR]
  RewriteCond %{REQUEST_URI} (^|/)site-default/ 
  RewriteRule ^.*$ - [F,L]

  RewriteCond %{REQUEST_URI} "^/~?[-_.a-zA-Z0-9/]*$"

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !(favicon\.ico|robots\.txt)

  RewriteRule ^(.*)$ index.php?it=$1 [L,QSA]

</IfModule>
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

I don't think your htaccess file will matter in this case, because the error you are getting is one that involves a file access not controlled by apache. Since you mentioned it started when you moved a local project to the server, I'm guessing that something in your /site/assets/ isn't writable or some of the directories didn't make it over. Try to re-copy your /site/assets/ to your live server, and then double check that everything is writable. If it's a unix server where you have shell access, you can do it pretty easily just by executing this command:

chmod -R og+rw /site/assets
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

Can you clarify what you mean by disappears? Are you saying it gets deleted from the file system, or that something visually on the screen disappears? If on screen, is the file there when you save or come back to the page?

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

Thanks for the screenshots. This is strange–I've not seen this behavior before. I would think you'd get an error, but clearly none is appearing. Can you confirm that it started after you migrated the site to your live server? Are you getting any JS errors? (you may have to enable the JS console in your browser). What browser and version? Can you think of any other unique factors that might enable me to reproduce it?

Link to comment
Share on other sites
Nico Knoll Hero Member

Nico Knoll

Posted
  • Author
Posted

I guess that it started after I uploaded it to my server (first the erors later nothing).

I'm using Chrome on OS X. But it's the same with FireFox and Safari...

Oh, and I looked at the console and it returns first a status code 200 but with this answer: 

{"error":false,"message":"Page not saved (no changes)"}
Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

Hmm, that's interesting that it says there were no changes. Can you check your images field and make sure that you haven't defined a maximum number of files for it? Also, can you attach one of the non-working images, just in case there is something about the images themselves. Lastly, just to confirm, you have no image/file upload capability at present?

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

If you want to set me up with SSH or FTP access as a PW login, I'll be happy to take a closer look at it this week and hopefully track down why it's not working in this situation. Just drop me a PM or email my name 'ryan' at this domain, and we'll get it figured out.

Also, if you have the time, it might be worth trying to install a blank/fresh copy of the latest PW in another directory and just see if you can upload files there (using the default profile it comes with).  That would at least point to whether we should be looking at the server side config or something specific to the installation you are working with now.

Link to comment
Share on other sites
Soma Hero Member

Soma

Posted
Posted

I'm sure I got this error once but can't remember where and what it was. ( when testing with the new upload ajax module with apeisa)

There was something like this:

"No problem. Thanks anyway for the test session  It can be very confusing at times.

But then, what's about this php bug with php://input? it does work on php5.2.9..."

There was a bug in php -5.2.11 (i think) with php://input, but not sure why it still was working then.

---

Could it possibly be that the file rights are messed up on the server? Like php not same group as ftp user, and you uploaded files via ftp?

Link to comment
Share on other sites
Nico Knoll Hero Member

Nico Knoll

Posted
  • Author
Posted

I think I got a solution (not the best one, but one). I have to do a little core hack which deactivates HTML5 at the end of "InputfieldFile.js":

if (window.File && window.FileList && window.FileReader && $("#PageIDIndicator").size() > 0) {  
InitOldSchool();
//InitHTML5();  
} else {
InitOldSchool();
}
Link to comment
Share on other sites
Soma Hero Member

Soma

Posted
Posted

Glad you found a quick fix.

So then it looks like the html5 ajax uploader isn't working for you. This is a pretty new feature, it hasn't been tested much, and I did run into some similar situation and it was a long weird debugging session going on between apeisa and me I can't even tell what was all done (since private sent messages gets deleted when not expicitely checked).

I'm sure there's still possibly something causing issues with something in combination of your servers software config.

Link to comment
Share on other sites
apeisa Hero Member

apeisa

Posted
Posted

Defintely something we need to solve.

Soma: the issue we had was because $this->page->filesManager->path was incorrect and returned nothing - and because of that in your setup it tried save files to your root folder and that is why there were permission problems. The php bug #49286  wasn't the problem then (http://php.net/ChangeLog-5.php) and it definitely isn't now since Nico is running very recent version of php 5.3. But that was before Ryan build the actual file saving procedure, so there was very crude code at the moment. Also, the error message was different (it was permission problem then and because my code was wrong and it tried to save files on your webhost root).

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

Looking at the phpinfo link, it appears the open_basedir restriction is being used on this server. That prevents PHP from accessing files outside of the directory specified in that option. If your PHP's sys_get_temp_dir() function was returning a directory not included in the open_basedir, then that could feasibly cause the problem you are experiencing.

Nico, I'm wondering if you can upload this test.php script to your server and see what it does:

<?php
$tmpName = tempnam(sys_get_temp_dir(), 'test.txt');
echo "<p>Attempting to write to: $tmpName</p>"; 
file_put_contents($tmpName, "It worked, no problem here.");
echo "<p>" . file_get_contents($tmpName) . "</p>";

If it says "It worked, no problem here." then this isn't the issue. But if you don't get that, or if you get some error message, than that would mean there's a PHP config problem (and maybe something we can work around).

Link to comment
Share on other sites
Nico Knoll Hero Member

Nico Knoll

Posted
  • Author
Posted

I've got this message:

Warning: tempnam(): open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/l3s46:/usr/share/php) in /var/www/l3s46/html/nico-knoll.de/schiller/test2.php on line 2
Attempting to write to:

Warning: file_put_contents(): Filename cannot be empty in /var/www/l3s46/html/nico-knoll.de/schiller/test2.php on line 4 Warning: file_get_contents(): Filename cannot be empty in /var/www/l3s46/html/nico-knoll.de/schiller/test2.php on line 5

---

What would be the right setting for this?

Link to comment
Share on other sites
Nico Knoll Hero Member

Nico Knoll

Posted
  • Author
Posted

Ladies and gentlemen,

I got it!

It's a core hack again - but I changed the other one back. So I changed line 122 in "wire/core/Upload.php" from:

$tmpName = tempnam(sys_get_temp_dir(), get_class($this));

to:

$tmpName = tempnam(ini_get('upload_tmp_dir'), get_class($this));

Thank you for your help!

Greets,

Nico

Link to comment
Share on other sites
ryan Hero Member

ryan

Posted
Posted

I found something similar after googling around a bit, and someone suggested using upload_tmp_dir when there were open_base dir config problems on the server. it's already committed in the source if you want to grab the latest–please let me know if that resolves it? It sounds like they basically have a configuration problem there (or a PHP bug?) because PHP's sys_get_temp_dir() is returning a directory that it can't actually use.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...