temporary directory problem

David, 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.

David, 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?

Problem 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);
+ }
}

Awesome. 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?

of course ! just let me get back to my workstation. that nokia phone is pretty bad at cvs'ing and diff'ing :-)

Here's the patch for #3, including two other minor PHP warning fixes..

I 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!

I 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.

i 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!

Thanks 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.

Hi 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

Hi 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

Maria, 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:

.menu-31929, ul.links li.menu-31929 {
  background-image: url(/sites/default/files/imagecache/myimagecachepresetname/sites/all/themes/mythemename/myiconfolder/my-icon-name1.png);
  padding-left:27px;
  background-repeat: no-repeat;
  background-position: left;
  height: 27px;
}

.menu-5811, ul.links li.menu-5811 {
  background-image: url(/sites/default/files/imagecache/imagecachepresetname/sites/all/themes/mythemename/myiconfolder/my-icon-name2.png);
  padding-left:27px;
  background-repeat: no-repeat;
  background-position: left;
  height: 27px;
}

I can confirm this patch works just fine ! Thanks, everybody.

Had 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?

It would be great to integrate this into the next release.

@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.

After 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.

I think that the proposed patch needs further review and possibly be rewritten..

subscribing

Just thought I'd mention that I'm getting this error on the D7 dev release as well.

subscribing

confirm 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.

#23 worked for me

Committed to 7.x-3.x-dev. Thanks!

What about 6.x version ?

best 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!

Actually, 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.

no problem. next time just remove tags yourself ;-)

Just experiencing this in 6.x-2.4. Patch #23 doesn't work on 6x. So......