Image URLs not being generated properly by WYSIWYG Upload

Well your suggestion is correct.

temp is set on the initial upload. Until you dont save the node, the file will stay temp and will be removed after cache expire. On save though, the file will get permanent.
So it seems we have antoher issue where nodeapi save handler is not called, though the images stay temporary. Thats why your files are not working "randomly", or more precise after the cache clear.

What kind of nodes did you add those images too?

To be exact, after saving a node, every entry in the db for that node must have temp=0 - otherwise those images get removed.

I really have to thank you, its very rare that someone gives so detailed informations for debugging and actuall puts his own time into the issue before opening. Very apritiated.

Well i guess you have to debug it, as i cant properly reproduce it here.

We have to debug 2 things, or better, we could have to places of failure:

• The form-cache is somehow broken (transition) so the submit handler cant restore the cache properly( http://github.com/EugenMayer/wysiwyg_imageupload/blob/master/wysiwyg_ima...) ( cache not set / wrong from_build_id ) and so, when the node reaches nodeapi:update the node has no $form['#node']->imgupload_images ($node->imgupload_images) cant be handled (http://github.com/EugenMayer/wysiwyg_imageupload/blob/master/wysiwyg_ima...). As you see, users need that permission, are they granted?
• Somehow the code in http://github.com/EugenMayer/wysiwyg_imageupload/blob/master/wysiwyg_ima... is never executed

I guess you have to place some dpm() and see, what fails. Be sure to use the user, which caused the problem with other nodes before and grant him devel rights ( it could also be permissions related )

Well yes, this is getting ugly.

Well also the files are temporary uplaoded, that means they will get deleted by drupals file api during cron, thats rights (thats actually the idea of those temporary files).

No there should not be 2 entries for each picture until you dont use it twice. Every usage of a picture is an entry. ( Even in the same node ). So if you only have one usage of that picutre in one node, there should be exactly one entry. If thats not the case, that could be the path of the error probably.

Well just to give you a checklist for reproduction:

1. Be sure to use the same user (permission issues)
2. Be sure to use the same content type ( forum, comment whatever )
3. very important and ugly: Test all combination of submissions:
   1. Save->validation-error->Fix error->save
   2. Preview->validation-error->Fix error->save
   3. Preview->no validation error->save
   4. Save->no-validation error

Its important to test all cases, because they need to be covered due to very ugly form-api edgecases. Read about them in http://github.com/EugenMayer/wysiwyg_imageupload/blob/master/wysiwyg_ima...

Thats actually the issue i wait to be cleared before the 2.1 release, which currently only has very minor corrections and a new feature ( inline resizing ). This issue could be a major though

Thanks for the investigation, iam looking into that using a fresh install. Maybe i find time today

Finally i have fount time to get into this. A very odd behaivor of the drupal menu API was the cause mainly.

http://github.com/EugenMayer/wysiwyg_imageupload/commit/a91f2212ca68944d...
http://github.com/EugenMayer/wysiwyg_imageupload/commit/abf1577172b5147e...

should be working in the github master already and will be included in 2.2.
reopen if this still does not work out

Well i need more informations. I def. fixed the "double entry" issue and at least on of those missing nodeapi procedures.

I guess thats you site : http://bulldogsworld.com/f/general-bulldog-forum/were-very-sorry-about-a...

If yes, well seems like you dont need any help anymore. Pretty disapointed about your way to communicate there, sounds like i never responded and you are not responsible for anything you do on your site.

I have the same issue.
When i add an image to a node (node-type "blog") the image is not shown on the posted node (instead a text like this: "[[wysiwyg_imageupload:4:]]"). When i click on "edit post" everything is working fine. So i can see the image during the upload process and in my body text.

My database table "wysiwyg_imageupload_entity" has the following entry:

iid | fid | nid | cid | temporary | imagecache | style | title | alignment
4 2761 854 0 0 Big 0 picture.jpg imgupl_floating_none

Thanks for help.

Cregar your issue is totaly different...

read the installation docs and activate the Drupal Wiki Inlne Image input filter...

Unfortunately, I'm running version 6.x.2.2 and the problem that newmediaist found is still occurring as far as I can see it. I get these sort of URLs http://www.mysite.co.uk/sites/default/files/imagecache/width_640px/ which is missing the filename and sub-directories.

The image uploads fine to the server and is shown on the preview. It even saves the page correctly but then a day later the images are missing and I have to upload them again. There appears to be problems with cron and saving the file. I've been running my server to update cron every 5 minutes which could have something to do with it. It also seems to happen more with new pages, rather than pages already saved which is weird. Makes me think that if the cron runs too frequently and you haven't saved the page, then it loses the URL information.

I'd really appreciate some advice on the issue as it's really bothering me. Thanks for the module btw!

well i found an issue which will be released in 2.2 but iam still not 100% it covers the edge case. The problem is, its really hard to reproduce.

Finally i found it, iam pretty sure. Its bound to the way i set the cace (CACHE_TEMPORARY) and the timing when a cron runs. I changed the form cache to be permanent and delete it when i save the node in the nodeapi.

There was alos a browser bug which could cause this.

Thanks for all your effort in helping me out EugenMayer. Just noticed the new 2.3 version on the site, so I guess this will have the fix included? Thanks again, really appreciate this bug fix. Drupal without an image uploader in the WYSIWYG is so frustrating.

Yes 2.3 includes this

This seems to be the same problem, but I don't really understand what is said in much of the comments above, and I'm not sure if I should create a new issue or use this one.

After clicking on browse and selecting the file, the "Image Details" panel shows a number (eg 133) the alternative text for the image.

At that point the file has actually been placed into sites/default/files/wysiwig_imageupload/ (followed by [uid]/filename.jpg)

When I click "Insert" there is a broken image picture. When I click on it and select "Image Properties" it shows that it is looking at the url sites/default/files/imagecache/600px_wide/wysiwyg_imageupload/1/filename.jpg

When I save and then edit, then look at the content without rich text, it shows: [[wysiwyg_imageupload:133:]]

Using drupal 6.19
wysiwig image upload 6.x 2.8
jquery update 1.3.2 in status report, ( module 6.x-2.0-alpha1)
jquery ui 1.7.3 (6.x 1.4)
Jquery UI Dialog 6.x-1.10

Thank you for the great module, it really makes it easy for clients! I did have it working up to a few months ago, and I'm not sure what happened so that now it doesn't work. I updated to a different server, but the hosting company said that they checked the permissions.

Open a new issue, describe detailed what happens, maybe include Screenshots. Thanks

The maintainer of this module clearly has no sympathy for new users or even for those who WANT this module to work.

I encountered the same that many are reporting, and after reading his replies I have deleted the package from my system and will go with something else. I am a software engineer by trade whose main area of expertise in a language other than PHP.

I find Eugen Mayer's responses and attitude to all of you to be inexcusable and I strongly you to use a different package.

Botfx do you actually maintain any modules?
Do you

• ..spend you time for free for the sake of the community? In any point?
• ..answer the same questions again and again, eventhough they are
  1. In the documentation
  2. in the FAQ
  3. in 10 other issues?
• Answer and work on this issues on behalf of you free time?
• try to invest more then 2 minutes installing a module and read the documentation??
• ..writing up documentation for things you dont need to document for yourself?
• ..writing howto`s to clarify how things should work
• ..and see people ignore all this work and simply ASK the same question again and again without even try to invest 5 minutes of reading?

You have absolutely no respect for the work a maintainer does while developing and maintaining the module, developing features and ASK support questions he should actually not care at all? Why should he even ask and help others debug there system to find out the have memory usage problems, crappy modules installed braking X, Y, Z or similar? Do you really think thats the correct way to go? Could it be rather the case, that its the _developer_ of the site, whos job that is? Isnt it what he gets money for, not me? Is that what he is resposible to and what he admitted to when using open source software?

If you think you can do it any better, go forward. But pissing on other persons shoes without having a slightly clue about what they do is most probably the wrong way.

Do you really think _I_ need you to use this module? Or might it the other way arround, i give you the oppertunity to use the module as i released it and maintain it for the wide range of users?

No comment.

As I've mentioned elsewhere: 1. Well written and complete instructions that non-cli users can follow and the drush make works! Yipee. I was really tired of imce and the bridge ...