Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After uploading and then doing update received a "The selected file ... could not be uploaded, because the destination is not properly configured"
Once I disabled the module the problem went away.
Comment | File | Size | Author |
---|---|---|---|
#23 | 0001-fix-of-802862-by-garphy-temp-dir-error-aftr-fresh-in.patch | 925 bytes | geek-merlin |
#6 | menu_icons-fixes.patch | 1.33 KB | eMPee584 |
Comments
Comment #1
jmcintyre CreditAttribution: jmcintyre commentedDavid, are you still having this problem?
The same thing is happening to me. The temp directory I have configured in admin/settings/file-system is definitely valid, with permissions wide open (for now). It seems to be related to ImageCache, but I don't know why yet.
Comment #2
jmcintyre CreditAttribution: jmcintyre commentedDavid, another question. I'm seeing the problem on a site I'm running through the Acquia Drupal Stack while it's in development. Any chance you're also using that?
Comment #3
garphy CreditAttribution: garphy commentedProblem comes from the cache flushing method. When there is no icon defined, the module tries to generate the CSS anyway, with empty content.
I circumvented the problem by applying the following condition (this is SVN diff on my private repo, I can diff on the official CVS if needed) :
--- menu_icons.module (révision 7675)
+++ menu_icons.module (révision 7686)
@@ -251,7 +251,9 @@
$css .= theme('menu_icons_css_item', $item['mlid'], $image_url, $info['width'], $pos);
}
}
- file_save_data($css, menu_icons_directory_path(FALSE) .'/menu_icons.css', FILE_EXISTS_REPLACE);
+ if( isset($css) ){
+ file_save_data($css, menu_icons_directory_path(FALSE) .'/menu_icons.css', FILE_EXISTS_REPLACE);
+ }
}
Comment #4
jmcintyre CreditAttribution: jmcintyre commentedAwesome. Makes perfect sense, and explains why the problem went away after I began uploading icons. Thanks!
Do you plan to submit this as a patch?
Comment #5
garphy CreditAttribution: garphy commentedof course ! just let me get back to my workstation. that nokia phone is pretty bad at cvs'ing and diff'ing :-)
Comment #6
eMPee584 CreditAttribution: eMPee584 commentedHere's the patch for #3, including two other minor PHP warning fixes..
Comment #7
ayukko CreditAttribution: ayukko commentedI am having this same problem: "The selected file /tmp/file9LrzFa could not be uploaded, because the destination sites/default/files/menu_icons/menu_icons.css is not properly configured."
Directory "sites/default/files/menu_icons" and default option directory for icon already exist; menu_icons.module is patched according to the patch provided in #6 but I am still getting the error message.
I have noticed no menu_icons.css physical file is created in "sites/default/files/menu_icons" directory, although the second time I installed and enabled the module the folder already existed. The module version I have installed is the only one available at the moment, 6.x-2.4.
Please help!
Comment #8
j0e CreditAttribution: j0e commentedI also can confirm having this problem: The selected file /tmp/file*** could not be uploaded, because the destination is not properly configured. This tmp directory error persists; I've tried both of the patches above 3 & 6 with no luck.
Comment #9
j0e CreditAttribution: j0e commentedi cleared the caches without errors this time, by simply changing the imagecache preset from the menu icons default to another imagecache preset...hope this works for anyone else having the issue!
Comment #10
ayukko CreditAttribution: ayukko commentedThanks jOe for your post... I have tried doing exactly as you mention (flush caches, change default preset for Menu Icons) and the only thing I got was a new folder under imagecache :) Still getting the error.
Performing some research, I found a note saying this issue could be related to the /tmp folder not being correctly configured in the server information page of Drupal; I have already checked that as well and is working fine, the images I try to upload as icons for the menu are already loaded in the /tmp folder.
Comment #11
j0e CreditAttribution: j0e commentedHi Maria, i am not using the upload method. that could be the difference between our results. for each icon i use when configuring icons for my menus at: admin/build/menu/item/*/edit, i click use an icon, and then specify a path to the icon at sites/all/themes/mythemename/icons, perhaps that will work for you too.
other than that, if that workaround doesn't help, i can't figure out why it's not working in your case. are your permission settings relaxed enough for public writing to your files and tmp directories? i would assume they are if you have this tmp error only when the menu icons module is installed, and it disappears when uninstalled. anyway, best of luck. hope you can figure it out soon.
Joseph
Comment #12
ayukko CreditAttribution: ayukko commentedHi Joseph!
I am not using the upload method either...
I have also found a note saying the file named menu_icons.css is not created on the file anymore and it should be located under the files directory. Turns out the installation I have done (the only one available at this point) does not create such file. I have triedinstallig it twice with same result: no such file created. Would you be so kind to post one for me so I can use it?
Thanks in advance!
Maria
Comment #13
j0e CreditAttribution: j0e commentedMaria, I would assume that the reason it's not being created is that the write permissions aren't allowing you to write from drupal public write method on web site to your files folder. Did you try setting recursive chmod 777 on the files directory to see if the most relaxed permissions will help you?
My menu_icons.css file basically consists of all the menu icons on my computer, it's site specific and has the imagecache preset name, menu name, padding, height properties etc that don't pertain to your site unless you have telekinetic powers :) but here are a couple examples from the file anyway in case you want to track your menu icon numbers and try creating one for yourself and placing it in sites/default/files/menu_icons/menu_icons.css:
Comment #14
Simon Georges CreditAttribution: Simon Georges commentedI can confirm this patch works just fine ! Thanks, everybody.
Comment #15
dcrocks CreditAttribution: dcrocks commentedHad same error on 7.x dev version, soon as I enabled the module. Am I supposed to create the menu_icons.css file right away? Doesn't the module create them?
Comment #16
Simon Georges CreditAttribution: Simon Georges commentedIt would be great to integrate this into the next release.
Comment #17
j0e CreditAttribution: j0e commented@dcrocks the module is supposed to create the css file...
@simon georges the patch must work for a particular variant of the problem...i'm glad it worked for you, though it didn't work for me, and the awkward way i fixed it in #9 demonstrates that there is yet another issue related to this tmp problem that needs to be patched as well.
anyway, i for one an am extremely glad to know that this was the cause of my tmp problem. i thought it was my server config until i spent a long time uninstalling modules and finally discovered it.
Comment #18
dcrocks CreditAttribution: dcrocks commentedAfter some experimenting I found that the error consistently disappears after the 1st time icons are enabled on a menu. Looking at the code, the 'menu_icons' directory isn't created until the 1st call of 'function menu_icons_form_submit', which explains that behavior. I've never written a module, but it looks to me that the file that the code is trying to write is the 'menu_icons.css' file, which is done in 'function menu_icons_init()'. I'm not sure of that but I don't see any other file creation outside of the form logic. I think that the '$options['menu_icon']['enable']' test is OK because its value should be TRUE or FALSE. It seems that the directory and css file creation is being done at the wrong times in the module logic. I could experiment but I rather someone more knowledgeable review this and suggest an answer.
I think the patch above is wrong and may have undesirable consequences. Also note all my testing is with the 7.x dev version.
Comment #19
dcrocks CreditAttribution: dcrocks commentedI think that the proposed patch needs further review and possibly be rewritten..
Comment #20
paulgemini CreditAttribution: paulgemini commentedsubscribing
Comment #21
paulgemini CreditAttribution: paulgemini commentedJust thought I'd mention that I'm getting this error on the D7 dev release as well.
Comment #22
Oleksandr.Masovets CreditAttribution: Oleksandr.Masovets commentedsubscribing
Comment #23
geek-merlinconfirm this oneliner lets us get rid of this confusing error and setting RTBC
re-rolled against current dev
as this is a oneliner backport should be trivial.
Comment #24
dcrocks CreditAttribution: dcrocks commented#23 worked for me
Comment #25
skilip CreditAttribution: skilip commentedCommitted to 7.x-3.x-dev. Thanks!
Comment #26
skilip CreditAttribution: skilip commentedComment #27
Simon Georges CreditAttribution: Simon Georges commentedWhat about 6.x version ?
Comment #28
geek-merlinbest practice for that is:
* reopen against 6.x
* add tag
and now someone who works with that version (you?) may scratch their itch and
* submit a patch against 6.x-dev
and then pray to maintainers that they
* commit
see: http://drupal.org/patch/submit
to port a oneliner like this is a good start
happy patching!
Comment #29
Simon Georges CreditAttribution: Simon Georges commentedActually, there is no such code anymore in the 6.x-2.x, the 2.4 version was indeed buggy, but it seems a lot of the faulting code has been changed (and this peculiar one-liner doesn't exist any more ;-)). Sorry, I should have checked before mentioning the 6.x branch.
Comment #30
geek-merlinno problem. next time just remove tags yourself ;-)
Comment #31
deanflory CreditAttribution: deanflory commentedJust experiencing this in 6.x-2.4. Patch #23 doesn't work on 6x. So......