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)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Can you show a screenshot? It's hard to guess what's empty.

merlinofchaos’s picture

Hmm. Ihave a math expression field working just fine.

Can you clear caches? Maybe there's something strange going on.

merlinofchaos’s picture

Status: Active » Postponed (maintainer needs more info)
johnv’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Hm 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.

johnv’s picture

Priority: Normal » Minor
Status: Closed (cannot reproduce) » Active
FileSize
35.15 KB

I 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'. ;-)

merlinofchaos’s picture

Title: Empty layover for 'Math expression' when adding/editing Field » Empty modal for 'Math expression' when adding/editing Field

Changing title. Every time I read 'layover' I don't think modal nor overlay. :)

bojanz’s picture

I 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...)

dawehner’s picture

The problem is

      $form['alter']['help'] = array(
        '#type' => 'fieldset',
        '#title' => t('Replacement patterns'),
        '#collapsible' => TRUE,
        '#collapsed' => TRUE,
        '#value' => $output,
        '#id' => 'views-tokens-help',
        '#dependency' => array(
          'edit-options-alter-make-link' => array(1),
          'edit-options-alter-alter-text' => array(1),
        ),
      );

... Continue with further research.

dawehner’s picture

Status: Active » Needs review
FileSize
566 bytes
691 bytes

Here 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.

merlinofchaos’s picture

Committed the CTools patch.

dawehner’s picture

Status: Needs review » Fixed

And commited the views patch. Please test it folks, here it's working fine.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

rfay’s picture

Status: Closed (fixed) » Active

I 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.

rfay’s picture

Status: Active » Needs work

I guess it should be "needs work"

Jerome F’s picture

I 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.

dilari’s picture

Using 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.

ClaudeS-1’s picture

subscribe - also can't configure "custom text" field using the Ctools 7.x.1.dev and Views 7.x.3.dev

dawehner’s picture

Again 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.

dawehner’s picture

Status: Needs work » Postponed (maintainer needs more info)

which theme do you use?

dilari’s picture

FileSize
11.14 KB

I 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..

dawehner’s picture

The perfect example does not work for you?
I used the perfect example to provide a fix for the issue.

dilari’s picture

Hi 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)

SchwebDesign’s picture

FileSize
53.74 KB

subscribing, 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

SchwebDesign’s picture

also, 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)

neoglez’s picture

I *see* two problems here:
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.

/**
 * Prerender function to move the textarea to the top.
 */
function views_handler_field_custom_pre_render_move_text(&$form)

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.

neoglez’s picture

Title: Empty modal for 'Math expression' when adding/editing Field » Empty modal for 'Math expression' and 'Custom text' when adding/editing Field
Component: User interface » Code
Priority: Minor » Normal
Status: Postponed (maintainer needs more info) » Active
dawehner’s picture

So 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?

SchwebDesign’s picture

just 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.

neoglez’s picture

Well, 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:

    // Remove the checkbox
    unset($form['alter']['alter_text']);
    unset($form['alter']['text']['#dependency']);
    unset($form['alter']['text']['#process']);
    unset($form['alter']['help']['#dependency']);
    unset($form['alter']['help']['#process']);
neoglez’s picture

Posting 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.

neoglez’s picture

Status: Active » Needs review
dawehner’s picture

Status: Needs review » Needs work
+++ b/handlers/views_handler_field_custom.incundefined
@@ -19,31 +19,22 @@ class views_handler_field_custom extends views_handler_field {
+    $form['text'] = $form['alter']['text'];

This won't help because the values will not be stored anymore. Are you sure this works?

neoglez’s picture

Status: Needs work » Needs review
FileSize
1.85 KB

Thanks 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.

neoglez’s picture

Wrong patch :-(
Here the rightone.

dawehner’s picture

Thanks 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.

neoglez’s picture

I leave that to your consideration ;-)
although i dont't see why *all* users would have broken fields.

dawehner’s picture

You store the text in $options['text'] but the render_text method uses $options['alter']['text']

neoglez’s picture

Status: Needs review » Active

Well, 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:

$alter['text'] = $this->options['text'];
parent::render_text($alter);

..mm, not sure, searching further.. :)

dawehner’s picture

Personally i think the problem is a bug in ctools depedent.js. It should detach the js behaviour as well.

mstrelan’s picture

subscribe

rfay’s picture

This 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.

merlinofchaos’s picture

I'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.

merlinofchaos’s picture

Status: Active » Fixed

I just committed a fix to CTools to fix this.

merlinofchaos’s picture

Project: Views (for Drupal 7) » Chaos Tool Suite (ctools)
Version: 7.x-3.x-dev » 7.x-1.x-dev
Component: Code » User interface

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.