SQL error when saving comments

This error should not be related to your issue, that the plugin does not show up. Eventhough your SQL error is and issue and i fixed it : http://github.com/EugenMayer/wysiwyg_imageupload/commit/4e28f9fcd7dd020c...

The error fix is made removing the call to the function that fails. This function deletes the unused rows from sql tables, so removing the call there's no error but we can have some garbage in our tables.

The original error in _wysiwyg_imageupload_cleanup_temps() can be fixed with this patch.

are you using postresql?

The _wysiwyg_imageupload_cleanup_temps function gets called also at each cron run:
wysiwyg_imageupload.file.inc @line 286

@6 that is by design.

@4: please dont close issues :)

@2: are you using postgrsql?

@6 that is by design.

no problem about that :)
but the call @ line 286 seems to generate the same error even after applying the fix in #1
The fix in #2 so far solved the problem, even after removing the fix in #1.
At least on my system.

Thanks

I have the same error after updating yesterday and I use MySQL on a shared web-host (of quite reasonable quality & updated) with an extra database prefix.

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '* FROM 'dbprefix'wysiwyg_imageupload_entity AS wui LEFT JOIN 'dbprefix'wysiwyg_imageupload_e' at line 1 query: DELETE * FROM 'dbprefix'wysiwyg_imageupload_entity AS wui LEFT JOIN 'dbprefix'wysiwyg_imageupload_entity_revision AS wuir ON wui.iid=wuir.iid WHERE NOT EXISTS (SELECT fid from 'dbprefix'files WHERE wui.fid=files.fid) in .../sites/all/modules/wysiwyg_imageupload/wysiwyg_imageupload.file.inc on line 186.

Where 'dbprefix' is the name of the database prefix I gave when installing drupal. Note: on a shared webhost all my databases start with my client name; dbprefix is additional to that one, as well as the drupal database name.

Will try if un-installing and re-installing wysiwyg_imageupload has any effect: Ticked off the module and sub-modules => admin/build/modules/uninstall => deleting module. Then installing module 2.4 again.

I have to mention that Image_API, Image_cache, jQuery_UI, jQuery_Update, WYSIWYG, jQuery_UI_Dialog_API were on "Regulación" what is Spanish for something like kicking the module out on high traffic; the second box to tick per module... I haven't put it like that; my installation is instable as Drupal core can't handle my many modules; sometimes its ticking modules off and much more often putting them on regulation & often I have to process many times before modules are ticked on or off.
I corrected this too (although Drupal core has the bad magic to very frequently put them on regulation again or just not process part of the changes, especially together with the CPU throttling of my web-host)

=> ticking all 2.4 sub-modules on except for the 2.x upgrade => no more error => had something to do with upgrading database?

(after 5 times processing to tick of the regulation for: jQuery_UI, jQuery_Update, jQuery_UI_Dialog_API, they are still ticked on for regulation; where specifically to file an issue?)

NO: I get the same error back after cron.php and trying to run update.php, where the error message arrives before updating.
However: reloading update.php again (is that safe, or should I first continue an update with an error message at start?) doesn't show the error before update.
Running cron & checking some pages =>

Yes, after cron it comes back on /admin/build/modules and update.php

Yes i can confirm that the patch from #2 does the trick

Ok i guess we are getting near now.

We need 2 fixes, on in

#1 which actually fixes a special case were the cleanup function is called (and should not be
#2 For fixing the query itself

From #7: No, I'm using mysql.

i got the same problem here but i don't know how to apply patch i'm using windows 7 and i don't know much about coding :-(
can you guide me some more or can i manual delete (or add) some code? .

thank in advance

oranjer

If you open the patch file will see two lines of code. The first one (whic starts whith <) is the old line (the line number 186 in the source file: wysiwyg_imageupload.file.inc). The second line of code (which starts with >) is the new line. The only change to do is to substitute 'DELETE *' with 'DELETE wui, wuir'.

HTH

I will push those patches on github, then you can download it as a package, no need to patch.

Many thank @slerby , @EugenMayer for your kindness
you save my time.
oranjer

Experiencing the same error. Subscribing.
_{Note to self: e3}

patch commited to master, thanks guys for taking time to nail that one down. Will be included in 2.5

@EugenMayer - when will v2.5 with these fixes be out?

When its done :) If you are in a hurry, look at github.com/EugenMayer/wysiwyg_imageupload and download the tar of the master branch

Unti i did not fix the "images dissapear bug" i will not release 2.5.

I'm using Postgres 8.1.22 and was getting an error after running cron similiar to the one first mentioned and the patch displays a similar error. I found a solution that worked for me was to change line 186 in wysiwyg_imageupload.file.inc from

db_query('DELETE * FROM {wysiwyg_imageupload_entity} AS wui LEFT JOIN {wysiwyg_imageupload_entity_revision} AS wuir ON wui.iid=wuir.iid WHERE NOT EXISTS (SELECT fid from {files} WHERE wui.fid=files.fid)');

to

db_query('DELETE FROM wysiwyg_imageupload_entity USING wysiwyg_imageupload_entity as wui LEFT JOIN wysiwyg_imageupload_entity_revision AS wuir ON wui.iid = wuir.iid WHERE NOT EXISTS (SELECT fid FROM files WHERE wui.iid = files.fid)');

and although I haven't had an error with this come up yet, line 201, the syntax in postgres 8.1.22 will cause an error, which appears to be corrected by changing

db_query('DELETE r.*,e.* FROM {wysiwyg_imageupload_entity} as e LEFT JOIN {wysiwyg_imageupload_entity_revision} AS r ON e.iid=r.iid WHERE nid=%d',$nid);

to

db_query('DELETE FROM wysiwyg_imageupload_entity USING wysiwyg_imageupload_entity AS e LEFT JOIN wysiwyg_imageupload_entity_revision AS r ON e.iid = r.iid WHERE e.nid=%d;',$nid);

I see, well needs to be checked once again

Subscribing.. have noticed the same error in my logs. Using mysql.

I did not take @21 in at all. Its missing curly braces, i dont get the usage of USING here at all ( expects a col list, not a table list?) and seems to be something pgsql related specificly.

db_query('DELETE e,r FROM {wysiwyg_imageupload_entity} AS e LEFT JOIN {wysiwyg_imageupload_entity_revision} AS r ON e.iid=r.iid WHERE nid=%d', $nid);

Thats what is used now and i expect this to work for both, mysql and pgsql.

Fixed in 2.5

This doesn't work in postgres because you can not DELETE columns, only rows and you must use DELETE FROM and refine using the where clause. You can use USING in the query to alias tables. I'm unsure how my changes effect the query in mysql but they work in postgres. The postgres query I posted above works, the change to 2.5 doesn't.

iam not deleting rows,

e and r are aliases for tables

Yes, this looks like a postgres specific error. I posted the original information for anyone using postgres that runs into the errors that I did. I am sure that code can be included specifically for each db language that will allow this module to work with both db's, but I am unsure (not as familiar with mysql) on how to have the same query execute the same way on the both db's.

I see that you are deleting everything from the wysiwyg_imageupload_entity and wysiwyg_imageupload_entity_revision joined on iid where the nid=(specified node id), I believe the postgres query does the same thing. Please correct me if I'm wrong.

see above

Thanks, slerby. That patch worked for me (I'm running mysql). I also had to add a table alias for one of the subqueries because I do table prefixing in my install.

Here's a revised patch.

@30 ... that is already committed to 2.8.. no need for patches :)