I don't know whether this is a problem with your (outstanding) module or whether it is something else on my page causing a conflict. I recently added an ajax element to my node form page (which contains a number of formatter-selector autocomplete/nodereference fields. Anyway, once I submit, process and return results (loading them into an external-sourced iframe on the page), anytime I try to reference a node in one of the fields using field-level (not global-level) formatter selector options it triggers an "An HTTP 500 error occurred" alert popup, and apache records this error:
PHP Fatal error: Unsupported operand types in ../aef_formatter_selector/aef_formatter_selector.module on line 613
Any idea?
thanks
Comments
Comment #1
dellis CreditAttribution: dellis commentedhmm... guessing it has to do with the $_POST value changing from the time the form is loaded to the time the formatter selector widget is working on it...
lines 610-613:
Although I am not sure how to solve the problem... the $_POST data that I generate isn't related to drupal.. is there a way to reset this (or are you storing all of the previews in $_POST?)
update: hmmm... You use the same function in aef_image--that one has a descriptor: "// Build the new form against the incoming $_POST values so that we can render the new element."
I wonder whether, since I'm pushing my $_POST data into an iframe within a dialog box, there might be a way to differentiate between my $_POST and the formatter_selector's $_POST... or whether there is another way to recover the $form_state values to rebuild the drupal $_POST data...?
Comment #2
dellis CreditAttribution: dellis commentedWould it be possible to substitute $form_state['values'] for $_POST?
Comment #3
dellis CreditAttribution: dellis commentedComment #4
dellis CreditAttribution: dellis commentedComment #5
dellis CreditAttribution: dellis commentedThis is a print_r of my $form values for a nodereference/aef_formatter_selector-enabled field taken during the autocomplete formatter lookup function... is this right? It seems odd that you are storing the actual text string in the nid element instead of just the nid "3970"...
I'm still at a loss... basically, if I load my "Edition" node form, I can use your aef_selector autocomplete widgets without issue. But as soon as I use AJAX to add a new node to the database in a modal (iframe) box, any attempt to use your aef_selector autocomplete widgets fails.
It still seems like something is missing that you are relying on, but I haven't got a clue as to what it is. Absolutely any suggestions for what to try/do next would be hugely appreciated.
Thanks
Comment #6
ndeschildre CreditAttribution: ndeschildre commentedHello,
The error comes because in:
$form is empty, meaning
has failed. This is surprising since this part is based on the CCK AHAH behavior (CCK updating itself in AJAX, for example when you upload an image with an imagefield).
That is something I would like you to test: In the testcase where the Formatter Selector is failing (because trying to update itself in AJAX), I would like you to test an imagefield upload which will also update itself in AJAX.
Concerning
,
this is normal, nodereference is processing [nid][nid] = title [nid:nid] in their validate function, and replace it by [nid] = nid. You are too early to see it.
Meanwhile, I'll try to reproduce that.
Cheers,
Nicolas
Comment #7
dellis CreditAttribution: dellis commentedI am trying to narrow down the issue--seems like I'm learning a little bit more at each step. I've been making extensive use of watchdog() error reporting statements--inserting a ton of them into aef_formatter_selector.module trying to find the exact issue that I'm having. I've triggered these messages in parallel for your widget without my "add a node from an iframe code", and then also with my "add a node from an iframe" code.
The function where I'm seeing the problem (aef_formatter_selector_get_formatters) is full of these alerts:
1) placed at the beginning of the function with a print_r($_POST) value: Looks OK in both
2) place just after the $form_state = array('submitted' => FALSE): Looks the SAME in both
3) placed just after the $form_build_id variable is given the value of $_POST['form_build_id']: Looks OK in both
4) placed just after $form = form_get_cache($form_build_id, $form_state): Looks OK in yours, in mine the message value (print_r($form)) is empty...
5) placed just after the $form += array('#post' => $_POST, '#programmed' => FALSE,): Looks OK in yours, in mine the alert was never triggered--no watchdog command was issued
6) placed just after $form = form_builder($_POST['form_id'], $form, $form_state): Looks OK in yours, mine never triggers the alert
So it looks like the form_get_cache function is not generating the results I need AFTER I've added a custom node within an external-sourced iFrame modal above the original node form.
Comment #8
ndeschildre CreditAttribution: ndeschildre commentedHey,
I have just tried to use formatter selector on an external iframe (via the module AEF Embedded Edit), works great here.
I think it would help me if you could precise your usecase. What exactly is this custom node in an external sourced iframe, how it is placed ?
Maybe a few screenshot may help?
Cheers,
Nicolas
Comment #9
dellis CreditAttribution: dellis commentedInteresting, I added an uberimage field to that form... it works by default, but as soon as I try to add a node through my own ajax, then try uberimage again it gives the same error alert--my guess is that it is doing the same thing. I'll cut some screenshots for you now.
Thank you for your help!
Comment #10
ndeschildre CreditAttribution: ndeschildre commentedAnd also please add the javascript code of your own AJAX, and the corresponding PHP code. Seems this is what is messing things.
Comment #11
ndeschildre CreditAttribution: ndeschildre commentedOh, I just tilted.
Could you desactivate your Drupal page cache (set to 0mn) in admin/settings/performance, and try again?
(If it happen to fix things, you can look at [searching for the real address], otherwise don't bother, it's a tricky Drupal issue)
Comment #12
dellis CreditAttribution: dellis commentedmmm... no luck with turning off page cache... still the error...
Okay, so I've posted a video of the user-side of things to help explain what I'm doing: http://vimeo.com/13517842 (it isn't finished converting yet)
Then... here is the code:
The "Search content from NPR.org" page is the external php file loaded into an external-sourced iFrame, the js on that page that starts the problem is:
Comment #13
ndeschildre CreditAttribution: ndeschildre commentedThanks for the data. Unfortunately, I'm not seeing the video!
Comment #14
dellis CreditAttribution: dellis commentedThe php was long, so I figured I'd separate it out (I'm sorry about this--there is a lot of stuff going on, but basically I'm just creating a few different nodes and relating them to eachother). From the function that is called by: http://dev.myurl.org/ypm_npr_item_add_json (the path referenced in the js):
Comment #15
dellis CreditAttribution: dellis commentedSorry about that, the video has 26 minutes left before it is available: http://vimeo.com/13517842
Thanks again.
Comment #16
ndeschildre CreditAttribution: ndeschildre commentedOk great, last thing I would need before having everything to debug is an output example of http://api.npr.org/query?callback=?, with even better the PHP code corresponding to this.
I'll be leaving for today, but I'll review that tomorrow, with the video incoming.
Thanks,
Nicolas
Comment #17
dellis CreditAttribution: dellis commentedOkay, I've run a query and taken the resulting JSON data and converted it into a php array object--then used a pre print_r to display the results. They can be found in this file: http://www.yourpublicmedia.org/json_data_in_php.txt
This is the $_POST data I get back from the npr api and use to populate the various node values as seen in the php function above--I've stripped out the apiKey, but everything else is as it is delivered. Hope this is what you were looking for...
The video is live now, so you should be able to see it.
Thanks again for your help with this.
Comment #18
ndeschildre CreditAttribution: ndeschildre commentedHello,
Ok, the video makes things clear, I did already have this problem. The source of the problem is exactly the same one you got when you click "add more" and everything dissapear: cache_get() on the cache_form is failing, either because the entry is no longer here, or because of the code.
There is quite a lot of nodes discussing this, e.g.:
http://drupal.org/node/406050
That is why yesterday I was asking you to try to set the page cache to 0mn. It's a little complicated, but:
On your AJAX call, you make a lot of node_save(). node_save() contains a cache_clear_all() at the end of the function. cache_clear_all() call cache_clear_all('null', 'cache_page/block') which will call
$user->cache = time(); is the important part.
Then on aef_formatter_selector (or CCK or aef_image or whatever), you have
In form_get_cache, this is called:
Usually $user->cache > $cache->created is false, so that's ok. But here since we went through cache_clear_all because of the node_save, it is now true, thus returning NULL.
Then, since it is failing to fetch the cached form, it is unable to render the part of the form it want to replace, and all dissapear (when you click "Add more") or you get an error (formatter selection).
This problem is one of the very very few design misconception of Drupal: having the cache of forms being treated like all others caches (page, block, ...)
Several things to check:
- Set the page cache to 0mn in settings/performance
- If you are using the memcache module, do not put cache_form in it.
- If you are manually clearing the cache_form table from time to time, do not do it.
Being sure that cache_form is not cleared somehow, and that you have page cache turned off should fix things.
Unfortunately you will probably not want to disable page cache, but first let's try to validate this solution.
Cheers,
Nicolas
Comment #19
dellis CreditAttribution: dellis commentedmmm... thank you for your help (you really know this stuff!). Well, yesterday I had actually "disabled" my page caching and it still caused the same problems. But reading your response again, I activated the page cache and set it to "none" for time--sure enough it worked.
Do you think there might be a workaround for this--or am I in a "don't cache pages" or "don't use my node add code" position?
Thanks again--this is crazy!
Comment #20
ndeschildre CreditAttribution: ndeschildre commentedIndeed you really can't disable page caching, unless you are behind a proxy or CDN (our case).
The (dirty) workaround here would be:
That's dirty, and it will still fail if you happen to click "add more" in the middle of the AJAX call, but I'm not seeing a better way without hacking the Drupal core, which is a worse thing.
Drupal is really a well architectured thing, with some very rare bad design decision in it, this is one of them.
Cheers,
Nicolas
Comment #21
dellis CreditAttribution: dellis commentedhmm... I re-activated the cache (refreshing every 15 minutes) tried that the suggestion above, but no luck. Then I added watchdog reports at the beginning of my function to print the original "$user->cache", then the $user->cache after all of my node_save(s) and then finally once I'd reset it... anyway, they were all blank?
Comment #22
ndeschildre CreditAttribution: ndeschildre commentedOf course you put a
before?
Comment #23
dellis CreditAttribution: dellis commentedIs it possible that something like passing $User->cache along to my npr_api...php external php file's querystring, dump it into a div on the page, then use jquery to add it to the data array being posted to the php function?
I'm not sure how I would access the $user->cache data from the form page with php though (if this is even a remote possibility)
Comment #24
dellis CreditAttribution: dellis commentedahh... that would be an embarrassed "no"... !!! Looks like that is working for me! Luckily for me I'd rather get a little "dirty" than not get work done at all!!!
Seriously you have just saved me a lot of additional wasted effort. Thank you so much for all of your help.
Comment #25
dellis CreditAttribution: dellis commentedComment #26
dellis CreditAttribution: dellis commentedComment #27
ndeschildre CreditAttribution: ndeschildre commented\o/
Comment #28
ndeschildre CreditAttribution: ndeschildre commented