filemanager and component/filearea

filemanager and component/filearea

by A Guy -
Number of replies: 8

I have a local plugin I created. It has an mform. The mform has a filemanager like so:


 $mform->addElement('filemanager', 'fileuploadform', get_string('formupload', 'local_myp'), null,array('accepted_types' => array('pdf')));


The files get added to the files table but they are in "user" and "draft" component and filearea respectively.


After looking at the file api and various discussions here and elsewhere online I added code to check if the form has been submitted:


if($myp_admin_settings->is_submitted()){


and then I get the draftitemid

 if($draftitemid = file_get_submitted_draft_itemid('fileuploadform')){
        file_save_draft_area_files($draftitemid, $context->id, 'local_myp', 'myp_admin_form',0,array());
  }


But the files never move--they are still in user/draft component/filearea. So what am I missing? How do I get the files to move from user/draft to local_myp/myp_admin_form?


Thanks for your help!!!


Average of ratings: -
In reply to A Guy

Re: filemanager and component/filearea

by A Guy -
I guess everyone has started back to school . . . no replies . . . !!!!
In reply to A Guy

Re: filemanager and component/filearea

by Justin Hunt -
Picture of Particularly helpful Moodlers Picture of Plugin developers

Often you will find that it has actually saved but that the itemid is not right, so later you can not find it when you try to load it, or you have not implemented local_mvp_pluginfile function in your lib.php file correctly. If it truly has not saved, perhaps you are not getting the draftitemid back correctly.

It helps to open up the mdl_files table and see what the result of "file_save_draft_area_files' has been so you can start to track it down.

In reply to Justin Hunt

Re: filemanager and component/filearea

by A Guy -

Thanks. I know it is the correct draftitemid as I took the value returned and did a sql call from the mdl_files using it. It pulls the correct one. But also I have checked after each attempt to save it to the correct component/area and it doesn't. So I'm lost here.

In reply to A Guy

Re: filemanager and component/filearea

by Justin Hunt -
Picture of Particularly helpful Moodlers Picture of Plugin developers

Sorry to ask simple questions. 

But how do you know its not saving, what are you actually "checking?"

Have you opened the mdl_files table in phpmyadmin or whatever tool you use and looked at the last few entries right after you have attempted to save a new file? 

If its there does the saved file info look correct? I would match up the context, filearea, filename , and itemid against whatever I was using in other code to display/fetch that file.


In reply to Justin Hunt

Re: filemanager and component/filearea

by A Guy -

I was looking at the database table mdl_files with select * from mdl_files where itemid=xyz . . . the draftiemid value that was returned from the form submission. I was also just scanning the database select * from mdl_files. But I just fixed my issue. When I submitted the form I was check for is_cancel and is_submitted. If it was submitted via TRUE for is_submitted I then got the submitted the data from get_data(). That was the problem. I changed it from checking for is_submitted to just get_data. At that point the issue of file_save_draft_area_files saving the files from draft/user to the correct area and component was resolved. Seems simple but I guess if you want until the submissions returns it is too late, huh?


Anyway now the problem is that when I move away from the form and back the files don't get repopulated even though they are still in the database. I guess I need to do something on the back end and feed the values to set_data. I will research that. Thanks for the advice.

In reply to A Guy

Re: filemanager and component/filearea

by A Guy -

I wrote the pluginfile and put it in my lib.php file. It is found as I have test it by stopping the programming at the top, middle and bottom of that function. It returns the urls. I output the URLS but they don't show the PDFs. The URL strings are correct as I matched them to the my database fields and of course the domain is correct. So what could be the problem. Here is the error that gets printed out. Lots of people report this issue it seems. Like this person for example: https://stackoverflow.com/questions/22817009/moodle-development-error-in-new-plugin-module-with-file-manager And this person outlines the same solution the other person(s) followed, which I did: https://github.com/CARLOSEDUARDOVIEIRA/moodle-uploadfile And that just basically reiterates what the Moodle docs say: https://docs.moodle.org/dev/Using_the_File_API_in_Moodle_forms


So am I missing something?



Sorry, the requested file could not be found

Debug info:
Error code: filenotfound
Stack trace:
  • line 482 of /lib/setuplib.php: moodle_exception thrown
  • line 1885 of /lib/filelib.php: call to print_error()
  • line 4806 of /lib/filelib.php: call to send_file_not_found()
  • line 40 of /pluginfile.php: call to file_pluginfile()

In reply to A Guy

Re: filemanager and component/filearea

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Hi Mr Guy (could you put your full first name on your profile, as per the site policy?),

You haven't stated which exact version of Moodle you're using (as far as I've spotted), so the line numbers aren't that helpful ( https://github.com/moodle/moodle/blob/master/lib/filelib.php#L4806 isn't a call to send_file_not_found(), so you can't be using the very latest code).

At a guess, Moodle is unable to find the correct function in your plugin's lib.php. Are you sure you have a function called local_myp_pluginfile() in local/myp/lib.php ? (Taking the name of the plugin from one of your previous posts in this discussion, if your plugin is actually called something other than local_myp, then adjust the above as needed).

In almost every case, by far the easiest way to get the bottom of such problems is to put a breakpoint in the main pluginfile.php file, then step through a line at a time in your IDE to figure out what is going wrong (of course, you first need to install xdebug, use a suitable IDE and, optionally, install xdebug helper to make turning debugging on/off quicker).

In reply to Davo Smith

Re: filemanager and component/filearea

by A Guy -

3.5. It is not the latest. Yes, I did roll up my sleeves and trace the code. I found that it was a naming convention/contradiction issue actually which I suppose was my fault. When I saved the files from draft to the "plugin area" I was not naming the component like these file creation/download function expected and compared to what the actual plugin directorywas in the " local" directory. That is the "local_myp" was clashing with just "myp" . So I hard coded the correct naming convention _pluginfile function in lib.php. Now the PDFs download. Just took a while to detangle as there really are no consistent naming conventions I have found . . . again sometimes you are required to use "mod_whatever" or "local_whatever" and other times not . . . just "whatever".


Anyway it failed on this part lib/libfile.php I think it was as my plugin is a local plugin. But it found the directory and the component were named correctly. That is what led to me to realize the pluginfile function had a naming convention problem.

    } else {
        // try to serve general plugin file in arbitrary context
        $dir = core_component::get_component_directory($component);

        if (!file_exists("$dir/lib.php")) {
            send_file_not_found();
        }
        include_once("$dir/lib.php");

        $filefunction = $component.'_pluginfile';

        if (function_exists($filefunction)) {
            // if the function exists, it must send the file and terminate. Whatever it returns leads to "not found"
            $filefunction($course, $cm, $context, $filearea, $args, $forcedownload, $sendfileoptions);
        }

        send_file_not_found();
    }



Hopefully this helps someone else out there. Thanks.

Average of ratings: Useful (1)