Not working with HTML insert mode

Patch attached to fix this issue.

I've tested the patch and it solves the issue.

Thanks for the fix, Moonray!

mlsamuelson

That's a review.

Thanks for pointing that out. I think I've done a few reviews without changing the status today. I'm just getting the hang of reviewing patches. Will pay more attention to setting the status. (Didn't know I had the authority to do that.)

mlsamuelson

I am having the same problem (insert bumps to front page in html mode). I tried to apply the patch, but I keep getting the error:

patch unexpectedly ends in middle of line.  
patch: ****only garbage was found in the patch input.

This is what I typed in terminal (I am a bit of a patch noob), from the img_assist folder where I uploaded the patch:
patch < img-assist.patch
I tried it multiple times, I even took out the long line of *** at the bottom. Any suggestions? I would love it to work b/c I use img_assist all the time!

Thanks,
Maria

I decided to apply the patch manually, and it appears to fix the error. Thank you!
Maria

I do not do code, but since I manually patched this, I noticed that most of the changes were from 'edit' to 'edited' (which struck me as odd). However, the last two changes (lines 1023 and 1031) appear to move the output up the page, under a different function, with this difference: 'img_assist_insert_html', $form is now 'img_assist_insert_html_form'. Maybe that is the key change?

The reason I had to change it from $form['edit'] to $form['edited'] is because, even though MOST of drupal code got rewritten to use $_POST as the form variables array instead of $_POST['edit'], it still checks for $_POST['edit'] to see if it exist in the drupal_goto() function (common.inc). Now, in 4.7 our local form variable used to be $form['edit']['edit'], which was fine. Now, in 5, where $form['edit'] got dropped (and residual old code still exists) drupal gets confused.

In short, there was a conflict in variable names.

See common.inc, lines 299-304

  if (isset($_REQUEST['destination'])) {
    extract(parse_url(urldecode($_REQUEST['destination'])));
  }
  else if (isset($_REQUEST['edit']['destination'])) {
    extract(parse_url(urldecode($_REQUEST['edit']['destination'])));
  }

Somehow, the else part resolves to true, which overrides the destination to '', sending us to the front page of our drupal site.

In the above post I used $form and $_POST interchangeably, which is not entirely correct. Read it all as $_POST (instead of $form) and it should make sense (I think... urgh... too... early!)

Hi!
I have problems with patching the file, can you please write how should i do that or attach the allready patched module file.
thanks!

Leming15
www.excondo.com

I applied the patch, and it seems to work properly. I don't use tinyMCE, so I can't comment on that part.

I think, actually, that edited was the correct terminology. It's false the first time the form is requested. Once you hit the Insert button, it will re-request the form, this time with $edited being true, upon which it will use javascript magic to insert it into the parent textarea.

But I leave it up to you to decide which word to use for the variable. The code works. :-)

p.s.
You can attach .patch files (no need to append .txt)

I looked through the JS and the module's code, and it looks like you are right. The edit (now update) variable isn't really used other than in the tinyMCE's JS.

When the module calls drupal_get_form, that function checks for submission, and then proceeds with handling it.

I'd say you're good to commit.