Issues: nod_@drupal

How could i use Sticky table headers with overflow-x:scroll in a table?

Greetings mighty and powerful drupal developers!

I wonder whether it`s possible to use drupal sticky headers when a table has very wide width as in the screenshot given below.

It`s not possible to understand data in a table because there is only a first visible part of the table displayed in the sticky header.

Thanks in advance!

AttachmentSizeStatusTest resultOperations stickytable.png27.88 KBIgnored: Check issue status.NoneNone

Undefined index: group_rendered in options_form() (line 180 of /modules/views/plugins/views_plugin_style.inc)

Using openlayers 2.x and Views 3.x I get the following notices from the style popup.
So, var_dump($this->options); in /views/plugins/views_plugin_style.inc : options_form() :

array
  'grouping' =>
    array
      empty
  'data_source' => string 'openlayers_wkt' (length=14) Either openlayers form data are wrong either Views does not handle them correctly.
maybe related (Views issue): #1424744: Notice: Undefined index: group_rendered

Use RequireJS to load all JS

I'm making a new issue because there are other important aspect to talk about in #1033392: Script loader support in core (LABjs etc.) and the actual loading is just a part of it.

The patch here is quick and dirty, it's a proof of concept and could be much more optimized should we use AMD (Asynchronous Module Definition) for core js files/modules. I've browsed around core admin, enlabed overlay all is working but I haven't tested scripts in footer and the like. Should work but you never know.

I've used RequireJS because it's well documented and it supports AMD loading. An other loader could be used, but today, i'm liking this one. I had to use the order plugin, long term this should go away by default, dependencies should be declared in the module itself hence loading even faster.

I've added requirejs files in /misc but that should be somewhere else ideally.

Apply the patch and see you page rendering time go down, way down. All js ever loaded in a script tag will weight around 5.6kb, the rest will be loaded after. If we go the AMD only road, it could go down to a 950 ish bytes file on initial load.

AttachmentSizeStatusTest resultOperations core-load-requirejs.patch19.05 KBTest request sentNoneView details

Rename url() alias parameter to is_alias

Whoops....

This is normal, internal URL:

/drupal7x/node/1

This is alias URL

/drupal7x/test

according to url function, alias is set to FASLE by default, BUT:

(dpm output)

    url('node/1') => /drupal7x/test

    url('node/1', array('alias' => TRUE)) => /drupal7x/node/1

    url('test') => /drupal7x/test

    url('test', array('alias' => TRUE)) => /drupal7x/test

Looking back in history:
D5 return TRUE
D6 return TRUE
D7 return TRUE

Core Usages of url [590 occurrentces], seems like it may affect a lot of place and modules.. hope im wrong..

Attached 2 patch, one is fixing the bug, 2nd is turn into TRUE by default.

AttachmentSizeStatusTest resultOperations url_fix.patch610 bytesIdleFAILED: [[SimpleTest]]: [MySQL] 33,340 pass(es), 5 fail(s), and 0 exception(es).View details | Re-test url_set_to_TRUE.patch1.09 KBIdleFAILED: [[SimpleTest]]: [MySQL] 33,340 pass(es), 6 fail(s), and 0 exception(es).View details | Re-test

Sticky table headers messed up

Sticky table headers in a clean install of Drupal 7 are messed up. They are pushed to the side whilst leaving white gaps in the middle.
It appears not to be related to a specific theme as both Bartik, Seven and Stark show the same issue.
My guess is that it is more a javascript and/or CSS problem.

See some screenshots here: (hopefully they stay on the gyazo server)

Safari
http://gyazo.com/c77f1ce90a37df5d680ef957e82314e9 (Bartik theme)
http://gyazo.com/3e74408cf925d2fda1549a851f237369 (Seven theme)
http://gyazo.com/d5eded91d440d82b23e795e370447367 (Seven theme)
http://gyazo.com/b0fd7bc4031ca8118bade6937785217b (Stark theme)

Google Chrome
http://gyazo.com/8dfefff4b96130f104b1ad25240c59d5

Firefox: doesn't have this issue
http://gyazo.com/9036834bd17bd8f2aa94514f7549c4f2

Opera: doesn't have this issue
http://gyazo.com/16cb4b12a00876aa2e3894a3f8ed53bb

Some say that it is related to the Overlay module but when this module is turned off and caches are cleared the issue still shows.
(side note: uploading files here is a pain.. the first gets uploaded but the second always gets stuck.. therefore only one uploaded image :) I'll have to report another issue for that as well I guess )

AttachmentSizeStatusTest resultOperations Safari-5-1-2-Seven2.png91.21 KBIgnored: Check issue status.NoneNone

Views compatibility with Quicktabs

I use both Views with exposed filters and Quicktabs together.

I would like to be able to redirect a view exposed filters search back to quicktabs.

This requires to set the view 'path' variable to string starting with # sign.

However when I set the view path to something like "/#qt-frontpage_quicktabs"
and when a user tries to filter view results using an exposed filter , the view wrongly redirects replacing # sign with %23 code: "/%23qt-frontpage_quicktabs"

I would like Views to allow path redirects to /# instead of /%23.

Remove dead code: progress.upload_callback, progress.error_callback

I can't find any piece of code using this.progress.update_callback and this.progress.error_callback on this line: ajax.js

My google-fu and ctrl-F fu is not strong enough.

The way this thing works is that a PHP settings gives the name of a JS function that is used as callback. It's wrong, that's not how you use javascript and If this needs to be supported and there is actual code using it, I'd be happy to do it properly (this could use some jquery ui to make it work).

Here is a patch that gets rid of it, it uses eval() and gets in the way of #1417378: Remove eval() from tableHeader JavaScript and #1415788: [Meta] javascript cleanup.

AttachmentSizeStatusTest resultOperations core-js-remove-ajax-dead-code.patch1.45 KBIgnored: Check issue status.NoneNone

Replace $('selector', domelement) with $(domelement).find('selector')

Title says all. Changing this only saves one function call but it saves this call hundreds of times. there is a comment in the jQuery source that assure both are equivalent. It's on the sexy 169 line.

  • If a $(domelement) is used more than once it goes in a variable with a $domelement name in the closest scope around it,
  • removed useless $() wrapping that were already jQuery objects,
  • I fixed two leaking global vars in this patch too (in tabledrag),
  • I checked everything but I'm sure sun will end up questioning that ;) be my guest for testing.

If you look closely at the patch you might wonder why context was passed as an argument to attachBehaviors instead of $(context), saving a few thousand useless calls. I'm wondering too.

And tabledrag needs love badly.

This patch will confilct with the other on about changing .size() to .length and most likely the one about eval in tableHeader.

AttachmentSizeStatusTest resultOperations core-js-select-with-find.patch83.02 KBIdlePASSED: [[SimpleTest]]: [MySQL] 33,341 pass(es).View details | Re-test

[Meta] javascript logging and error reporting

There are several aspects of this.

  1. AJAX error reporting is too obnoxious #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" when a link is clicked or form is submitted during an AJAX operation
  2. don't use alert to display errors #505598: Convert alert() to ui.dialog
  3. have a Drupal log function that follows error reporting levels #1419648: javascript error reporting interface
  4. auto-logging of JS errors by binding a function to window.onerror #1206974: Add a window.onerror JavaScript handler
  5. having a watchdog interface: #727278: Add watchdog interface for javascript code to use and #1206974: Add a window.onerror JavaScript handler

We need to decide:

  1. What to expose: watchdog interface, javascript logger (it could use watchdog too), change alert to dialog;
  2. If something like firebug-lite should be available for retarded browsers to allow easy debugging,
  3. specific error level reporting for JS,
  4. maybe something I forgot.

Let's talk about this.

javascript error reporting interface

This patch adds a Drupal.log(message, type) function that wraps around the console object and falls back to alert for retarded browsers.
Types available are the same as in drupal_set_message(), each is mapped to the relevant console method: status is console.log(), warning is console.warn() and error is console.error(), unknown types just add a 'mycustomtype: ' prefix to the message.

I'm using values from error_level to choose which error to display with a catch

  • ERROR_REPORTING_HIDE displays nothing,
  • ERROR_REPORTING_DISPLAY_SOME (which is called Errors and warnings in the admin form) only displays warnings.
  • ERROR_REPORTING_DISPLAY_ALL All of the above plus errors.

There will be changes to make to this patch but i'm not sure at which level, I need some help integrating this properly. I'm not talking about a watchdog interface there are other issues for it.

AttachmentSizeStatusTest resultOperations core-js-error-reporting-piggy-back.patch2.51 KBIdleFAILED: [[SimpleTest]]: [MySQL] 33,350 pass(es), 2 fail(s), and 3 exception(es).View details | Re-test

Pages