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.