Hi to all,
I tried to substitute a PDF from the file field with a new one. with the search/upload button But there was no success.
Whats the common procedure for that.
> I tried to substitute a PDF from the file field with a new one.
> with the search/upload button But there was no success.
Just so that I understand you correctly: You have an existing record that has a PDF file attached to it. And now, you'd like to replace this PDF file with another one. Is that what you're after?
> Whats the common procedure for that.
To associate a different file with a particular record, you can do either of the following:
1. Edit the record (i.e. display the record in edit view), click the upload button to specify your new PDF file, and hit the "Save Record" button.
2. Or, alternatively: login as admin, goto edit view, and edit the file path/name in the 'file' field so that it points to any other file (that's stored already on the server or at a remote location).
Either of this should associate your new file with the record. However, currently the previously associated file is not removed from the server automatically, since it may be also used by other records, and since it makes it easier to revert any erroneous action. This latter issue (i.e. the removal of existing files) could surely see some improvement, but it wasn't of much priority until now.
Hope this addresses your question, if not, please elaborate.
>1. Edit the record (i.e. display the record in edit view), click the upload button to specify your new PDF file, and hit the "Save >Record" button.
That's what I tried to do in my database and in your demo database
The record 1813 of you database contains a non existing pdf file.
I tired to substitute with the procedure above but nothing happened. Just the same behavior as in my database, with the exception that the old file in my database is present.
> That's what I tried to do in my database and in your demo database
> The record 1813 of you database contains a non existing pdf file.
The refbase demo database is an exception here, since, for security reasons, upload of files has been disabled there. I.e. the demo database does not contain any files, and all existing links to PDFs point to nowhere.
> I tired to substitute with the procedure above but nothing
> happened. Just the same behavior as in my database, with the
> exception that the old file in my database is present.
I've just tried again to upload a new PDF file for a record that already had a PDF file. This works flawlessly in my local refbase installation. The old file is replaced by the new one, and clicking on the PDF file icon displays the new file.
A few questions:
- Have you confirmed that the initial upload of files still works flawlessly? I.e. can you upload a PDF file for records where there isn't one already?
- What are your file-specific settings in 'ini.inc.php'? Could you report your settings/values for these variables:
Also, I note that my comment from my previous email (about the removal of existing files) was incorrect, at least when using the refbase default settings: If you have '$renameUploadedFiles' set to "yes" in 'ini.inc.php' and have specified a naming scheme that always generates an identical file path & name for a given record, then uploading a file of the same type (i.e. with the same file extension) overwrites any previous file.
>- Have you confirmed that the initial upload of files still works flawlessly? I.e. can you upload a PDF file for records where there >isn't one already?
no it doesn't work :-(
I tried with full server path and with relative path to the rebase directory ->see below
seems to be be any PHP restriction ...
I have Revision 1009
/ // Created: 12-Jan-03, 17:58
// Modified: $Date: 2007-09-27 15:33:03 +0200 (Do, 27 Sep 2007) $
// $Author: msteffens $
// $Revision: 980 $
$filesBaseURL = "files/"; // e.g. "files/"
$moveFilesIntoSubDirectories = "never"; // possible values: "never", "always", "existing"
$dirNamingScheme = "<:firstAuthor:>/<:year:>"; // e.g. "<:firstAuthor:>/<:year:>"
$renameUploadedFiles = "yes"; // possible values: "yes", "no"
$fileNamingScheme = "<:serial:>_<:authors:><:year:>"; // e.g. "<:serial:>_<:authors:><:year:>"
$handleNonASCIIChars = "transliterate"; // possible values: "strip", "keep", "transliterate"
> >- Have you confirmed that the initial upload of files still works
> >flawlessly? I.e. can you upload a PDF file for records where
> >there >isn't one already?
> no it doesn't work :-(
So, you're not able to upload *any* file to your database, independent from the fact whether a record already contains a PDF or not?
Did file upload work for you previously? If so, have you done any changes to the server setup since then? Have you verified that the path given in '$filesBaseDir' is valid and is readable+writable by the Apache/PHP server?
Have you tried uploading a different PDF file, or a very small one? Does this work better?
The PHP server has limits for the maximum post size which can be changed in 'php.ini'. See:
Your file-related options from 'ini.inc.php' seem to be ok for me.
>So, you're not able to upload *any* file to your database, independent from the fact whether a record already contains a PDF or not?
no I am not
>Did file upload work for you previously?
I remembered that I put the only available pdf file in the first day of the installation with FTP, so
the answer is no.
The memory restriction for files is 8 MB, all switches are set as required in the link above from you.
Max memory usage is 32 Mb and the upload file is 136 kB
The path should be ok, because the path in the file field shows to the directory which is in the stored in the ini.inc.php file.
The phptmp path is working (for session cookies)
Does refbase or PHP requires to store files in the PHPTMP directory temporarily?
is there any visual change during the upload?
There is a delay and refbase returns to receipt.php? nothing else
I think it is not an Xammp because it is a Linux webserver with Apache and I have not root access, because its a webspace from our provider.
the values from the PHP 4.3.11 info file
iconv support enabled
iconv implementation glibc
iconv library version 2.3.2
> >So, you're not able to upload *any* file to your database,
> >independent from the fact whether a record already contains a PDF
> >or not?
> no I am not
Ok. If you can't upload any PDF files then it's worth re-checking the basic setup:
- the PHP temp/session directory must be accessible & writable by Apache/PHP
- if you're on a hosted service, your Internet Service Provider may have given you a specific temp directory path which you may need to put into variable '$sessionTempDir' in 'ini.inc.php' (this variable was added in the most recent update of the SVN trunk and should be included in r1009).
> Does refbase or PHP requires to store files in the PHPTMP directory
Yes. PHP copies files to the server's temp directory first, refbase fetches them from there, renames them, and moves them to their final destination. As mentioned, using the most recent version from the SVN trunk, you can explicitly set the temp directory in variable '$sessionTempDir'.
> is there any visual change during the upload?
You mean from refbase? If so, no, and I wouldn't know how this could be done.
> There is a delay and refbase returns to receipt.php? nothing else
If you cannot get it working, you may need to input echo & exit calls into various locations of file 'modify.php' to debug this further.
If you have (or can setup) a local refbase installation using XAMPP for comparison, and get PDF upload working there, this may also help with debugging.
>Ok. If you can't upload any PDF files then it's worth re-checking the basic
> the PHP temp/session directory must be accessible & writable by Apache/PHP
maybe I am not right, but I think am not able to login with session cookies if the phptmp directory is configured wrong.
But the value of phptemp is correct;
There should be no server sided problem. You could try:
with a php file - it is working with the same upload directory.
By the way there is no need in this script to setup the phptemp dir.
Maybe this is an hint for you.
I can monitor the upload process in the sessiontmp directory.
After that the file is deleted and lost
Upload of files does work with all refbase installations that I have access to, so I fear that I won't be able to help you any further since I'd need to be able to replicate your problem.
As mentioned earlier, the only thing that might help is to input echo & exit calls into file 'modify.php' to track this down.
Could yo give me a hint where the line is between phptmp upload and copy from phptmp to the files directory.
Id would be more easy for me.
I found an error:
// Copy uploaded file from temporary location to the default file directory specified in '$filesBaseDir':
// (for more on PHP file uploads see <http://www.php.net/manual/en/features.file-upload.php>)
echo ("move file tmp path: ". $tmpFilePath ." dest path ". $destFilePath);
move file tmp path: /home/www/web25/phptmp/phpspc284 dest path /home/www/web25/html/uni/refbase/4366_IESM2008Test2008.pdf
The dest path should be
as used afterwards to show the files with the php icon.
And the refbase directory attributes are set to 755 so there is no writing allowed.
Therefore the file goes lost.
Maybe you could check the directory rights to put out an error message with attributes and directory name.
I just sent you a test file privately for debugging purposes but I see that you could track this down already.
Could it be that the value of your variable '$filesBaseDir' is set incorrectly? It should point right to the "files" directory within your refbase root directory.
As an example, if your refbase root directory is located at:
and if you have variable '$filesBaseURL' set to a subdirectory "files" within that refbase root dir:
then variable '$filesBaseDir' should be set to:
Please verify that this is the case for you. Also make sure that all of these file paths and URLs end with a slash.
I agree with you about the error checking, though. And there are many more places where error checking could be improved.
I tried your modified file and found nothing wrong....
Then I changed the code to
if (move_uploaded_file($tmpFilePath, $destFilePath))
echo "\nresult_move_upload: TRUE \n"; // DEBUG
echo "\nresult_move_upload: FALSE \n"; // DEBUG
echo "\n tmpFilePath: " . $tmpFilePath . "\n"; // DEBUG
echo "\n destFilePath: " .$destFilePath['unwritable']. "not writable\n";
echo "\n destFilePath: " . $destFilePath . "\n"; // DEBUG
And the result:
Warning: move_uploaded_file(): SAFE MODE Restriction in effect. The script whose uid is 674 is not allowed to access /home/www/web25/html/uni/refbase owned by uid 33 in /home/www/web25/html/uni/refdb/modify.php on line 1204
I changed the refbase directory during a new installation from refbase to refdb
So there is additional to my stupid error (stearing to refbase and did not see that it should be refdb) any server misconfiguration.
And thats very strange there is no directory refbase and when I change the ini file f.e to
the error is:
Warning: move_uploaded_file(/home/www/web25/html/uni/refdbxx/files/4366_IESM2008Test2008.pdf): failed to open stream: No such file or directory in /home/www/web25/html/uni/refdb/modify.php on line 1204
Warning: move_uploaded_file(): Unable to move '/home/www/web25/phptmp/phpmj9l36' to '/home/www/web25/html/uni/refdbxx/files/4366_IESM2008Test2008.pdf' in /home/www/web25/html/uni/refdb/modify.php on line 1204
but in both cases and if the directory rights are too less is_writable($destFilePath)) returned false, maybe you could add this in to your code.
Sorry for the long tread caused by an stupid error from me.
Hi Knut, thanks for the update. Based on your feedback, I'm not entirely sure if you could fully resolve your problems (it looks so, though) -- if not, let me know. And, as mentioned earlier, make sure that variable '$filesBaseDir' points to '/home/www/web25/html/uni/refdb/files/' and set it's permissions so that's it's writable by Apache/PHP.
I'll try to improve the error checking for file uploads.
Thanks & best regards, Matthias
if I remember right the script install.php created the directory ../refbase.
PHP is (mostly) running as a module on Internetserver and the directories created with PHP are getting the PHP rights.
Normally the script should change the rights just after writing, so that FTP user are allowed to change them again.
maybe you could add this for Internetserver users.
After that I had no permissions to chnge the directory rights and refbase didn`t work.
so I did a new installation with FTP in Refdb and forgot to change the Filebasedir ... since the first days of the installation...
Everything works fin except file upload which I did not use.
Additional I got struggled with the remarks from this lines.
$filesBaseDir = "/home/www/web25/html/uni/refdb/files/"; // e.g. "/usr/local/httpd/htdocs/refs/files/"
$filesBaseURL = "files/"; // e.g. "files/"
I thought Filebase dir is /home/www/web25/html/uni/refdb/
and filesBaseURL is files/ together it would result the complete path, because the remarks are e.g "files" and I wondered about the name FileBAse*URL* :-)
Maybe the story of the error is helpful for you
Thanks again for your help
Hi Knut, thanks for the follow-up.
> if I remember right the script install.php created the directory ../refbase.
Currently, this is not the case. The 'install.php' script does not create any directories. refbase does only create directories upon file upload, and only when '$moveFilesIntoSubDirectories' is set to "always". And in that case permissions will be set to 0770.
I understand your confusion about '$filesBaseDir' and '$filesBaseURL', and I've added a note about it on my ToDo list.
Best regards, Matthias
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.