Http error 200 occurred on flag (but not on un-flag)
bobdalob - June 17, 2008 - 12:14
| Project: | Flag |
| Version: | 5.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
This occurred with a new flag created post-installation (upgrade Views Bookmarks --> Flag)
flag.module includes the patch provided here: http://drupal.org/node/271078
The flag toggles and registers successfully however the pop-up error appears only when flagging, not un-flagging.
I'm fairly sure this didn't occur with an existing flag upgraded from Views Bookmarks, but I'm not certain (it has since been deleted). I'm happy to go back and restore an earlier database to run through it again - would like first to see if anyone else has encountered this error, or has an explanation..
#1
Hi Just upgraded from views bookmark to flag, and get the same error report
On ie7 the error is on both Flag and unflag
All other actions work
#2
Hmm, HTTP error 200? That's odd since that's the status code for a successful request. Do you have devel module query logging enabled? It might be interfering with the returned JSON from the JavaScript request.
#3
I subsequently looked up that code and thought it was strange. Unlike comment #1 I do not get it for un-flagging in IE7. It happens for flags in IE7, FF3, Safari & Opera 9.50 but never un-flags.
I have jquery 1.26 installed via the jquery update module. This test site has the same config as when using views bookmark, which definitely did not encounter this.
Later, when I have some more time, I'll try some elimination by disabling certain modules, see if I can identify any conflict there.
#4
Forgot to answer: no, devel module is not installed.
I'm afraid I don't know javascript well enough to debug or comment with adequate proficiency however could this be anything to do with the variation in the respective .js files for flag and views_bookmark? In particular I'm drawn to the omission of code concerning clean urls (line 40 of views_bookmark.js)
I have clean_urls enabled.
#5
(I don't have acess to Drupal right now.)
function flag_page(...) {...
$js = isset($_REQUEST['js']);
I wonder if this has anything to do with the problem. Could you try changing this to
$js = 1;?#6
(I've just tried to mimic the problem on my local D5 but failed (the migration VB -> Flags went smoothly, btw). I tried both clean and non-clean URLs. I'm about to try this on a different server.)
#7
I tried to reproduce the problem on a different server (my blog), but failed again.
bobdalob, could you please try the following?
Open 'flag.module' in a text editor, locate the line:
$js = isset($_REQUEST['js']);And change it to:
$js = TRUE;Does it make a difference? (afterwards restore that line.)
#8
No difference ("1" or "TRUE").
No luck either when disabling 3rd party modules that use jquery.
MySQL 5.0.45
PHP 5.2.5
Apache 2.0.63
jquery 1.26
Any other tests/suggestions?
#9
Is your site stored on a public server I can see? (You can send me the link privately if you wish.)
#10
Okay, traced it. I went on a bit of hunt through the database, post un-install.
The culprit is an entry in the actions_assignments table which remains even when the action had been deleted from flag config - that explains why I was getting nowhere on a fresh install.
To recreate:
Create a flag or use the default - config doesn't matter
Just check that flag ops work OK on a node.
Create a new flag action (I used "Unpublish after flagging threshold" with default values and assign to an action).
Test.
Actions 5.x-2.5 installed.
Hope this helps!
ps. sorry, this is not on a public server
#11
But where, and how, does the action get deleted? It doesn't appear in your 'To recreate' list.
I hope my question makes sense. Nate would surely be able to figure this out.
#12
I think so. Sorry if that was a bit 'lean'.
What I was trying to say is that the module works fine UNTIL a flag action is created.
Creating a flag action introduces the problem, period, and it will not go away until 1) this action is deleted in admin/build/flags/actions AND 2) the flag entry is manually removed from the actions_assignments table
Note: no 'aid' value is stored for the flag entry in the assignments table.
If this doesn't make sense then maybe you are not able recreate the issue - let me know.
#13
Superficial 'actions' test works for me, but I'll test it more thoroughly later today, I hope --it takes time.
Your description does make sense, it's logical, it's just that I'm not familiar with the module's 'actions' support --it, and 99% of the code, is Nate's work. I hope he chimes in.
#14
Manual resolution:
I note the numeric value for the flag action's "aid" from the actions table and give the same value to the action's corresponding entry in the actions_assignments table (which was missing 'aid' value).
My flag ops then work fine as do their triggered actions.
That's about as far as I can go under my own steam although I'm happy to stick with this in terms of the discussion and testing. Why it's not getting written is beyond me. Hope this helps focus the problem anyway.
#15
An 'http error 200' occurs because of some PHP error on the page. To see the PHP error message, instead of this javascript alert box, either click the flag link when javascript is turned off, or click the link with the right mouse button (and 'open in new window').
I've just encountered this 'http error 200', while working the Actions support. I deleted some PHP function that implemented an Action, and the PHP error was, naturally, "Call to undefined function blahblahblah() in ...".
#16
Using Moofie's suggestion I got the error that undefined function _actions_get_hook_aids was being called. This is in line 823 of the flag.module and is a function included in the flag.actions.inc file. It seems this wasn't getting loaded by hook_init. I temporarily moved the include_once to the top of flag.module and the error no longer occurs. This isn't an ideal fix as the include was checking for the presence of actions.module. The suggestion in drupal api under hook_init is that where a problem like this occurs move the problem code into hook_menu with !may_cache.
#17
Steve, thanks. It might be that you fell victim to this bug:
#279532: "An HTTP Error 200 Occured" when using Actions 1.x
(It was fixed already, but in the 'dev' version.)
If this isn't the case, then your report isn't very helpful: you didn't say what version of Drupal you're using and whether you're using the 'beta3' version or the 'dev' version of this module. And, if you're using D5, whether you're using Actions 1.x or Actions 2.x.
#18
You're right - after posting the follow-up I realised that the function I referred to wasn't in the flag.actions.inc file at all (sort of obvious given the function name). With actions 5.x-2.5 installed it no longer gives the error.
#19
#20
This specific bug hasn't been fixed yet. 'bobdalob' explained it in comment #10. Today I fell victim to it, and I did find a "fix" which I'll commit later.
#21
(The probablem is probably specific to D5, not to D6.)
Yes, that's the problem I had today with my Drupal 5's Actions. I added a safeguard in the code against this, so I believe it's "fixed".
http://drupal.org/cvs?commit=134434
http://drupal.org/cvs?commit=134433
I know why this happened on my system and it may very well be the reason it happened to you too:
The Actions module has the following code:
function actions_save(...) {...
db_query('INSERT INTO {actions_aid} VALUES (default)');
$aid = db_next_id('{actions_aid}_aid');
...
In other words, it generates an ID using two different mechanisms: an auto incerement field, and some unrelated Drupal mechanism. (Fortunately, only one mechanism is used in D6.)
These two mechanisms can go out of sync. In my case the entry in the {sequence} table somehow wasn't correct. After I set it to the correct number the problem was gone.
Buy why did this happen in the first place? I don't know. Perhaps the Flag module isn't at all the culprit here. What I don't like it that our module touches the internals of Actions.
temp
Automatically closed -- issue fixed for two weeks with no activity.
#22
Automatically closed -- issue fixed for two weeks with no activity.
#23
.
#24
Nevermind the comment above.
#25
i wasn't sure from reading the thread what the status of this bug is, but I can confirm I am getting this error message as well with Flag 5.x-1.0-beta3 and Drupal 5.10. I am getting it both with and without flag actions module and Actions 5.x-2.5.
Can't be much help beyond that, but thought I'd let you know. Thanks for all the hard work.
ian
#26
Ian, could you please provide the text of the PHP error? The Javascript box doesn't say much.
Comment #15 has a tip:
IMPORTANT: what version of Flag are you using? You're saying something about a "flag actions" module, so this can only be "dev", not "beta3", because this sub-module is very new.
#27
Ian, please try out the new "dev" version, it has a completely new Actions support (thanks to Nate). Reports on the old "beta3" version aren't needed anymore.
#28
Sorry about that. I just updated to the 2008-Sep-06 5.1-dev release and am still getting a http error - although now it is the following:
An HTTP error 0 occurred.
/flag/flag/user_bookmarks/2780?destination=node%2F2780
This is different than the 'http error 200' that was recorded yesterday. I only get the error message when flagging the content (not unflagging). Also, when javascript is turned off the error does not show up. Let me know if there is any more information I can provide.
#29
Ian,
Right now, because of a very recent commit to CVS, things are a bit fragile, so we'll just have to wait a bit till things get fixed. I'll notify you in this thread.
You probably clicked the the link only once, so you didn't trigger the action (because when you're clicking a "flag this!" link you don't trigger actions registered for the "unflagging" event, and vice versa.)
#30
Ian,
I've just released 'beta4'. Please check it out (remember to visit Drupal's 'update.php').
I believe it would solve your 'http error 200'.
However, you say you now have 'http error 0'.
Maybe it's jQuery's fault. Please try to upgrade it, and report back.
#31
Automatically closed -- issue fixed for two weeks with no activity.