I would advise against using
This is because it could pose a problem when you use .htaccess on your administrator directory. For example, with Akeeba Admin Tools
I would prefer using the media folder as well.
You can also serve the hashed files with their proper original names like this:
If you write a small User Plugin, you can use something like this to create the folder.
class PlgUserExample extends JPlugin
public function onUserAfterSave($user, $isnew, $success, $msg)
// do something
This may not answer your question directly, but I wanted to give another point of view on this question.
I would try to avoid as much as possible storing documents that you can generate. Reason: you need to decide on folder names / file name, which later are hard to change. It may use too much space and could pose security issues.
Of course this depends on ...
Just thought I'd throw in my 2 cents (some good points in hashing the filename).
I recently had a similar issue. Instead of worrying about .htaccess, I just save the files above public_html, with a component parameter specifying the path, then using PHP's readfile to fetch and output the PDF.
Won't work with all hosts, but for most applications it's ...
You should add it to your controller, probably controllers/record.php. Override save function.
public function save($key = NULL, $urlVar = NULL)
// Upload your image
// Save item
"Failed to move file" error
This came from wrong $dest value. Destination has to be full path.
$dest = "media/com_mycom/img/".$...
There is a free module available at JED that can be configured to allow users to upload files to a folder with their username. Take a look at Simple File Upload. I've used it for one project, and it works fine, but at the end it depends on your specific requirements.
From the description:
It includes the following key features:
Multiple modules on the same ...
One error is $src = $file['tmp_name'];. $file isn't defined. You're should use $file1 there.
Another thing is that JFile is one of the classes which don't autoload for some reason. So you need to either register it in the autoloader or require_once it.
I would do something similar to what Lodder suggested for the actual uploading part:
I recently encountered this XMLHttpRequest error myself. The root of the problem caused 3 different issues.
SOLUTION: In my case, the problem was caused by an incorrect setting for the public $live_site variable in the configuration.php file (which is located in the Joomla root folder). The website was https://website.com but I had set the
Never store any user generated files in the component directories. You may end up loosing them during an update of your component (if not done properly) or for sure when the user uninstalls it.
The correct place to store such files is actually the "images" folder. It's the place where the user will be able to manage the files easily using the media manager.
I solved the issue. Problem was that when insert query was called in a loop 2000 times, deadlock occurred and returned a blank page. The solution to this is to construct one single insert query and then insert the values. Following is the code I added in model file -
Instead of calling insert method in loop I formed the insert values array:
$getValues = ...
You can write a component and define build and parse methods (AKA YOURCOMPONENTBuildRoute and YOURCOMPONENTParseRoute functions) in your component's router.php instead of creating physical directories. Then, you need to create a menu with alias of user or users and link it to your component.
Using the following directory as a root for all invoices is perfectly fine:
However, what I would recommend doing is hashing the file name once the invoice is generated. Like so:
Either that or, for each invoice, create a hashed directory ...
A couple of things. First, verify this is a bug by using the deprecated but still working JRequest to get the file data. I've had to resort to using this method myself recently for a file upload need.
$file = JRequest::getVar('file_upload', null, 'files', 'array');
If that doesn't work still, simply try dumping the $_FILES['file_upload'] request ...
The short answer is there's an "easier" way. The assumption being you need to provide a means for a user to upload a file as part of the core configuration of the module. Since there isn't a mechanism to override extension configuration layouts in back-end views, the best solution IMO is to use the media field instead for file uploads.
This will open a ...
I finally solved this by using $jinput->files->get() as in below :
Note the doc which puts all upload files in an array in the Jinput object here $files = $jinput->files->get('docs');
* Retrieves the hello message
* @param array $params An object containing the module ...
I had the issue again today, renaming the htaccess only without disabling Admin Tools and then updating worked for me. So it seems to have to do with the rules, set in the htaccess by Admin Tools.
Initially given answer:
For the update error "Ajax Loading Error: forbidden" try:
1) Disabling Admin Tools (if installed / component + system plugin)
By default, the file permissions on Joomla extracted files are 644 and the folder permissions are 755.
If you're seeing something different, then, as @jdog mentioned above, you will need check your umask settings (if you have a system administrator then I suggest you let him handle this). umask is used to remove deny default permissions (it is not used to ...
Make sure of the following:
The file/folder permissions are correct on the tmp folder. Typically, they should be 755.
The ownership is correct on the tmp folder. If you are running a cPanel/WHM environment, then the folder should be owned by the cPanel user. If you're running Plesk, then the folder should be owned by www-data.
I think I have a good idea where the error is. You are using $this->getFileName() to get the files original name, then you mutate the filename using normalize(). At this point you have a new file name, but the system doesn't realise that this is the filename to be used forevermore.
Basically, you will either need to rename the file in your file system ...
Maybe look at other PHP values like max_input_time or some of the other suggestions in
max_input_time sets the maximum time, in seconds, the script is
allowed to receive input; this includes file uploads. For large or
multiple files, or users on slower connections, the default of 60
You can extend the save() method to get this functionality :
public function save($data = array(), $key = 'id')
// Neccesary libraries and variables
ini_set("display_error" , 1);
// Get input object
$jinput = JFactory::getApplication()->input;
To me it seems to be almost a one to one copy of the backend "list items / edit item" views of com_banners. Except you want to upload an image instead of using the internal media manager.
Create those 2 views and the needed tasks and methods with the image field as a normal text field.
When this works as you want it to, you add the image upload.
The harder ...
I think you have got muddle up here. When you install an extension, you already uploading a zip file. So once Joomla had processed this zip, the files are already on the server. You cannot "upload" a file from one directory to another. You need to "move" or "copy" it.
You the code you'll need to use will either be:
Do your file movement tasks in postflight function of your script.php file
function postflight($type, $parent)
// do it here
This function get called after copying files from your package, databases gets updated etc.