0

Using ExtJS 4.2.1 I added a paging toolbar to a grid panel. Everything works fine except that the toolbar is rendered malformed. The page input field is far to small and has some weird frames around it. With a little luck I can type something into the field but I can't read anything. I see this with both default theme, neptune and gray theme and it is the same for Chrome and Firefox:

enter image description here

I used the default themes. Any idea about this?

In case this is a theme or CSS related problem (is it?) here is what I am including currently (trying neptune theme):

<link rel='stylesheet' id='extjsstyle-css'  href='http://127.0.0.1/wordpress/wp-includes/js/extjs/resources/css/ext-all-neptune-debug.css?ver=3.8.1' type='text/css' media='all' />

<script type='text/javascript' src='http://127.0.0.1/wordpress/wp-includes/js/extjs/ext-dev.js'></script>

When adding the following include as proposed in another thread it gets a little better (frames little more centric) but still no number visible and toolbar still much to high:

<script type='text/javascript' src='http://127.0.0.1/wordpress/wp-includes/js/extjs/ext-theme-neptune.js'></script>

This is the code that fails for me:

var dummyStore = Ext.create('Ext.data.Store', {
    storeId: 'DummyStore',
    pageSize: 1,
    fields: [ 'Data' ],
    data: [ { Data: 0 } ]
});

var pagingToolbar = Ext.create('Ext.toolbar.Paging', {
    store: dummyStore,
    dock: 'bottom',
    displayInfo: true
});

var panel = Ext.create('Ext.grid.Panel', {
    title: 'Test',
    store: dummyStore,
    columns: [ { text: 'Data', dataIndex: 'Data', flex: 1 } ],
    height: 550,
    width: 620,
    renderTo: 'myHtmlDiv',
    dockedItems: [ pagingToolbar ]
});

However I don't think this problem is data store related.

I did not do any stylings on my own.

UPDATE: If I copy the essential code and the includes into a blank HTML file, everything is displayed properly. Obviously this is a problem that arises due to something that Wordpress adds to the page. In the moment I have no clue how to tackle such a problem.

Silicomancer
  • 8,604
  • 10
  • 63
  • 130
  • Are you doing any overrides or custom styling for text fields (which the toolbar uses)? – Mark Peters Mar 27 '14 at 15:33
  • Any errors in the console? Without a complete example that demonstrates the problem, we're just grasping at straws. – Mark Peters Mar 27 '14 at 16:04
  • By the way, the ExtJS paging grid example (http://dev.sencha.com/deploy/ext-4.0.1/examples/grid/paging.html) creates the toolbar and assigns it in the `bbar` config, if that makes a difference. – Mark Peters Mar 27 '14 at 16:08
  • I tried the bbar method, it makes no difference. Also no errors on the console. I updated the question and added a demo code. Is there a way to check for a CSS/styling problem? – Silicomancer Mar 27 '14 at 19:02
  • 1
    My first action would be to inspect the element in the Chrome web development tools, see what CSS the border is coming from, and work backwards from there. – Mark Peters Mar 27 '14 at 19:32
  • 1
    Here's a JSFiddle for your example: http://jsfiddle.net/bdtVz/1. As you can see, it works fine with the 4.1.1 Neptune theme. So really wherever the problem is occurring, it's with stuff you haven't shown. – Mark Peters Mar 27 '14 at 19:42
  • By the way are you really using version 3.8.1 of the Neptune theme with ExtJS 4.2.1? I would expect they wouldn't be compatible (and your screenshot certainly looks nothing like the Neptune I know from ExtJS 4+). – Mark Peters Mar 27 '14 at 19:43
  • No, the screenshot was classic theme (I think). I tried some of the included themes but none worked. "3.8.1" is the version of wordpress I use. I didn't notice the version parameter. I removed that artifact by adapting the corresponding wp_enqueue_script call but that did not change anything. I will try what I can find out about CSS using Chrome. I will need some time, I never debugged such problems before. – Silicomancer Mar 27 '14 at 20:42

2 Answers2

0

Using Chrome developer tools I compared the HTML representations of the input field table of my broken toolbar and the Sencha example. There are differences. The broken input field sub tree has:

"numberfield-1014" -> "top: 13px" instead of 1px
"numberfield-1014-bodyEl" -> additional class "x-form-trigger-wrap-focus"
"numberfield-1014-inputEl" -> additional classes "x-form-focus x-field-form-focus x-field-default-form-focus"

Thinking more about this.... CSSs could accidentally change the formatting of the input field (based on element classes and a lot of other element features). But how does it come that the classes of the wellformed and malformed elements are different? CSSs do not change class attributes, do they? Where could this difference come from?

I also checked the CSS rules. I could identify one rule in the wordpress twentyfourteen theme that makes the outer frame visible:

table,
th,
td {
    border: 1px solid rgba(0, 0, 0, 0.1);
}

This is part of the reset section of the theme. When disabling it, the frame disappears.

Another rule is this one:

.entry-content td,
.comment-content td {
    padding: 8px;
}

It prevents the input field from showing correctly. After disabling this only the vertical positions of all items in the bar must be fixed to make the bar look correctly.

Any idea what the root cause of these effects is?

Silicomancer
  • 8,604
  • 10
  • 63
  • 130
0

I did not find a satisfying solution. Also the manufacturer of ExtJS (Sencha) could not give me a solution. It seems currently the only way to safely embed ExtJS content without CSS collisions is to use an iframe. I read about similar problems using other JS frameworks too so I suppose this generally is a problem.

Silicomancer
  • 8,604
  • 10
  • 63
  • 130
  • Note that all the Ext css is namespaced with `.x-foo` classes. The problem is likely that something in wordpress is overwriting a global rule somewhere that is causing an issue. – Evan Trimboli Mar 31 '14 at 07:33
  • Yes, right. I actually found the responsible WP rules (see my older answer). Still I was not able to understand why. E.g. that very basic table/th/td reset rule was able to overwrite an ExtJS rule but ExtJS rules should always be more specific. – Silicomancer Mar 31 '14 at 07:43