Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I added a new field "Global: Math expression" to a view using the 'old' UI. It worked well.
Then I updated to a Views version with new UI. Now, when I edit the field, the layover 'Configure field: Global: Math expression' is empty, so I cannot edit the contents. The same goes when i add a new field. I am using:
ctools 7.x-1.x-dev (2011-Mar-27)
views 7.x-3.x-dev (2011-Mar-30)
Comment | File | Size | Author |
---|---|---|---|
#34 | fixed-empty-modal-issue-1118570-2.patch | 1.85 KB | neoglez |
#33 | fixed-empty-modal-issue-1118570-1.patch | 1.85 KB | neoglez |
#30 | fixed-empty-modal-issue-1118570.patch | 1.44 KB | neoglez |
#23 | Capture2.PNG | 53.74 KB | SchwebDesign |
#20 | 2011-06-14_001004.png | 11.14 KB | dilari |
Comments
Comment #1
dawehnerCan you show a screenshot? It's hard to guess what's empty.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedHmm. Ihave a math expression field working just fine.
Can you clear caches? Maybe there's something strange going on.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedComment #4
johnvHm must have been the moon..
Yesterday the layover showed a greyish/greenish title area with text, and the white area showed nothing, only whitespace.
Now the situation is OK.
Comment #5
johnvI am able to reproduce this error in Views 7.x-3.x-dev (2011-Apr-16):
- Create a view/display with any field + a Math Expression;
- Show Math Expression: it's OK, press Cancel;
- Show Any field: it's OK, press Cancel;
- Show Math Expression: it's empty!
Please see the atttachment for a graphical definition of 'empty'. ;-)
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedChanging title. Every time I read 'layover' I don't think modal nor overlay. :)
Comment #7
bojanz CreditAttribution: bojanz commentedI reproduced this on two different installs a week back.
I add the field, the dialog is empty, I hit escape, reload, click again, it's fine. Happened in Chrome. Didn't have time to debug it further (since a reload allowed us to continue forward...)
Comment #8
dawehnerThe problem is
... Continue with further research.
Comment #9
dawehnerHere is a patch for both ctools and views.
The #id was used before, but now that depedency supports custom wrappers for fieldsets(with the ctools patch) this works fine.
Tested on title and math field.
Comment #10
merlinofchaos CreditAttribution: merlinofchaos commentedCommitted the CTools patch.
Comment #11
dawehnerAnd commited the views patch. Please test it folks, here it's working fine.
Comment #13
rfayI still have the exact problem described in #1131424: Global: Custom Text cannot be configured today, with current views and ctools. The same workaround still works: Switch between displays when it happens, and switch back.
Comment #14
rfayI guess it should be "needs work"
Comment #15
Jerome F CreditAttribution: Jerome F commentedI couldn't configure Global: Custom Text on a block display before the view was saved.
My view has only a block display and I was editing it and didn't save it. Then I saved it and could edit Global: Custom Text.
Once I edit the view after cloning the block I get the same problem, then I save again and can configure it normally.
Comment #16
dilari CreditAttribution: dilari commentedUsing the latest views (7.x-3.0-beta3) and ctools(7.x-1.0-alpha4) this issue still remains with the global custom text. I can reproduce it everytime when I edit a view. When first editting any other field or filter and then editting the custom text. It does not happen when you edit the custom text directly when in gui.
I noticed it also happens with domain acces filter. I was unable to set the value for true or false, the checkboxes simply where not there, after saving the view and re-opening, going directly to that filter, I was able to set the value. This is all on a 'page' view.
Comment #17
ClaudeS-1 CreditAttribution: ClaudeS-1 commentedsubscribe - also can't configure "custom text" field using the Ctools 7.x.1.dev and Views 7.x.3.dev
Comment #18
dawehnerAgain the question is can someone provide an easy to reproduce test case?
http://drupal.org/node/1118570#comment-4375176 is a perfect example for this.
Comment #19
dawehnerwhich theme do you use?
Comment #20
dilari CreditAttribution: dilari commentedI use the default admin theme "seven 7.2"
As for reproducing: It's simply always when I use global custom text field in any view, after first editing any other field, the text-edit field does not show.
I can still reproduce with that same 'perfect' example
see screenshot.
thanks..
Comment #21
dawehnerThe perfect example does not work for you?
I used the perfect example to provide a fix for the issue.
Comment #22
dilari CreditAttribution: dilari commentedHi Dereine,
just to be sure I've just done a fresh install with only ctools (dev 9-jun-11) and views (dev 17-jun-11) and the issue remains.
Steps to reproduce:
create a new view with fields.
add global custom text
fill in some value
click save
click on the title field, close it again
then click on the customtext field
The input field is not there
Dilari.
(I've tried both Firefox 4.1 and Chrome)
Comment #23
SchwebDesign CreditAttribution: SchwebDesign commentedsubscribing, same here with
Drupal 7.0
Chaos tool suite 7.x-1.0-beta1
Views 7.x-3.0-rc1
Attempting to add Global: Text area to "No results behavior"
screenshot for me is a bit different than the original post on http://drupal.org/node/1131424, however
Comment #24
SchwebDesign CreditAttribution: SchwebDesign commentedalso, i did implement ctools patch in http://drupal.org/node/1118570#comment-4377862
(the views part of the patch was already done in my version apparently)
Comment #25
neoglez CreditAttribution: neoglez commentedI *see*
twoproblemshere:1.- Pass $form by reference in views_handler_field_custom_pre_render_move_text, at the momment it's passed by value.The form is returned, no need to pass it by reference.2.- How in earth FAPI kows that views_handler_field_custom_pre_render_move_text must be called on the class views_handler_field_custom, i.e. views_handler_field_custom::views_handler_field_custom_pre_render_move_text (deducted from $form['#pre_render'][] = 'views_handler_field_custom_pre_render_move_text'; in views_handler_field_custom.inc line 30), i think only by doing this function static or something.
Comment #26
neoglez CreditAttribution: neoglez commentedComment #27
dawehnerSo the first part isn't a problem as you described ...
About 2)
If this class is loaded the full file is included. So you have the function views_handler_field_custom_pre_render_move_text
availible.
So when fapi renders the form now, it can just use views_handler_field_custom_pre_render_move_text.
Could it be that if you have form cache activated the pre_render method can't be found and so it's displayed empty?
Comment #28
SchwebDesign CreditAttribution: SchwebDesign commentedjust FYI for those of you who need this to work NOW... the work around i found was to open the Global Text Area edit form in another browser tab, thus avoiding the modal dialog. (middle mouse-button click in FireFox). This then loads the form in another tab as expected.
Comment #29
neoglez CreditAttribution: neoglez commentedWell, somehow i thought the function views_handler_field_custom_pre_render_move_text belong to the class but actually it doesn't.
The content is being rendered but it's hide (display:none), fieldset-wrapper-ctools-dependency issue??
Also by removing this lines the issue is gone:
Comment #30
neoglez CreditAttribution: neoglez commentedPosting patch. I removed the pre_render function, i'm not pretty sure is that could bring (bad) concecuences becouse things done there are suposed to influence only the *appearence* and not the logic.
Comment #31
neoglez CreditAttribution: neoglez commentedComment #32
dawehnerThis won't help because the values will not be stored anymore. Are you sure this works?
Comment #33
neoglez CreditAttribution: neoglez commentedThanks for the catch!
I think this is one of the *cleanest* way to do this, so keep things encapsulated in the class, avoiding to much redundance (redefining the textarea), etc.
Comment #34
neoglez CreditAttribution: neoglez commentedWrong patch :-(
Here the rightone.
Comment #35
dawehnerThanks for your continuous work in the issue queue!
I'm wondering whether this is the right approach, because for example all users would have broken fields.
Comment #36
neoglez CreditAttribution: neoglez commentedI leave that to your consideration ;-)
although i dont't see why *all* users would have broken fields.
Comment #37
dawehnerYou store the text in $options['text'] but the render_text method uses $options['alter']['text']
Comment #38
neoglez CreditAttribution: neoglez commentedWell, yes :(
One situation here is that i can see the text rendered (without the patch) but i can not find the (wrong?) dependency that is hidding the textarea.
Anyway i think the approach of encapsulating the whole behavior in the class is not bad, maybe overriding the render_text method?? something like:
..mm, not sure, searching further.. :)
Comment #39
dawehnerPersonally i think the problem is a bug in ctools depedent.js. It should detach the js behaviour as well.
Comment #40
mstrelan CreditAttribution: mstrelan commentedsubscribe
Comment #41
rfayThis remains very much an active issue.
The workaround remains pretty easy: Just go switch to another display and then switch back and then you can edit the item.
Comment #42
merlinofchaos CreditAttribution: merlinofchaos commentedI'm about 99% sure this is actually a bug in CTools and dependent.inc -- what's happening is that as settings build up, invalid settings from previous modals confuse dependent.inc -- because there's no way to tie the settings to a particular modal. dependent.inc needs a way to detach, or maybe to do a better job of not screwing up if the settings aren't valid. I'm not sure yet, I haven't taken the time to investigate the javascript seriously.
Comment #43
merlinofchaos CreditAttribution: merlinofchaos commentedI just committed a fix to CTools to fix this.
Comment #44
merlinofchaos CreditAttribution: merlinofchaos commented