Feed aggregator

Remove all specific process functions that flatten data from arrays to strings

Issues: nod_@drupal -

Problem/Motivation

Theme development for drupal is too complicated, with too many layers. We aim to remove the whole Process layer, but that can only be done in small pieces.

Proposed resolution

Since we can now flatten data structures to arrays to strings as part of the rendering process, we will need to go through all the process functions in core and remove this flattening. Examples of functions that can be removed include template_process().

Remaining tasks

- go through all process functions in core
- remove flattening everywhere it appears
- make sure flattening happens when content is rendered

API changes

?

Use data-* to store #states api informations

Issues: nod_@drupal -

This patch move the #states configuration away from Drupal.settings and into a data-drupal-states attribute on the relevant form element (it's data-drupal-states because data-states sounds like it'd be an easy naming confilct).

I had to move the drupal_process_states() call before drupal_render to add the attributes from this function.

The JS change is really straightforward, instead of getting the values from Drupal.settings it takes it from all the elements having a data-drupal-states attribute. The #states configuration is serialized in json inside the attribute. It's legit from a HTML standpoint, anything goes inside data-* attributes.

AttachmentSizeStatusTest resultOperations core-js-data-states.patch2.37 KBIdlePASSED: [[SimpleTest]]: [MySQL] 36,601 pass(es).View details | Re-test

Security:AJAX alert dialogs respect neither display_errors ini.php setting or $conf['error_level'] setting, exposing server info

Issues: nod_@drupal -

Problem/Motivation

If an exception or other error is thrown during an AJAX operation, the end user receives an alert dialog with an error message, and a fair amount of diagnostic information. This is great for a development environment. However, it's possible in a production environment, that a sysadmin might not want this information exposed to end users. (I've bracketed out and bold-faced the potentially dangerous information).

Here is an example of an alert dialog i get if I create a flaky db connection in my back end during an autocomplete session.

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: https://drupal7.dev.instance.local/taxonomy/autocomplete/field_ugc_colle...
StatusText: Service unavailable (with message)
ResponseText: PDOException: SQLSTATE[28000] [1045] Access denied for user '[db username]'@'[DB HOST]' [(using password: YES)] in lock_may_be_available() ([line 164 of /path/to/application/code/docroot/includes/lock.inc]).

Proposed resolution

Regular exception handling (to the browser window) consults the value of the error_displayable() function before rendering an error the client.

<?php
    if (error_displayable($error)) {
    // more logic to determine what/how to render error
?>

However, the AJAX error part of the function does not consult error_displayable(). It only checks if the error is fatal.

<?php
  if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
    if ($fatal) {
      // When called from JavaScript, simply output the error message.
      print t('%type: !message in %function (line %line of %file).', $error);

?>

My patch would change the AJAX error handling part of _drupal_log_error() to also consult the return value of error_displayable(), changing

<?php
  if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
    if ($fatal) {
      // When called from JavaScript, simply output the error message.
      print t('%type: !message in %function (line %line of %file).', $error);
?>

to

<?php
  if (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
    if ($fatal) {
       if (error_displayable($error)) {
        // When called from JavaScript, simply output the error message.
        print t('%type: !message in %function (line %line of %file).', $error);
       }
       exit;
   }   
?> Remaining tasks

Discuss. Critique. Review. Test, please. One thing I'm not happy with is that the header still says: Service unavailable (with message) in the xmlhttp request, rather than just Service unavailable.

User interface changes

None.

API changes

None.

META: write up lessons learned from D8MUX navigation prototype

Issues: nod_@drupal -

Problem/Motivation

The http://nav.d8mux.org/ prototype has completed phase 1 of its exploration of mobile navigation techniques.

But we need to take what we learned from there and implement what we learned!

Proposed resolution

Write up the lessons learned, then implement them.

Remaining tasks

First, Lewis needs to write up all the things we can implement from that prototype. He can do that in the comments of this issue.

Then, we (not Lewis) need to create individual issues for each of those things. And get to work!

:-)

User interface changes

An awesome new mobile navigation in D8.

JS aggregation should account for "defer" and "async" attributes

Issues: nod_@drupal -

Problem/Motivation

HTML5 proposes/solidifies asynchronous loading of JavaScript files based on two attributes: defer and async. Drupal has supported defer since at least D6, and support for async is currently in the works (#1140356: Add async property to script tags). Because of the special way these script tags are treated, we should be aggregating them into their own bundles.

Proposed resolution

Presumably, something will be added to drupal_group_js that groups "async" values with one another and "defer" values with one another, respecting their weights.

Remaining tasks User interface changes

None

API changes

Though this affects JavaScript aggregation, this should have little-to-no API impact.

Autocomplete AJAX call breaks because of additional URL parameters

Issues: nod_@drupal -

Hi there,

I have a site where the URL to editing a node can sometimes look like http://www.mysite.com/node/639/edit?destination=admin/content&language=fr

If I try to edit an autocomplete field of the node on this page, I see that the request sent back to the server looks like http://www.mysite.com/node_reference/autocomplete/node/slider/field_slid... (where 'test' is what I typed into the autocomplete field)

As you can see, Drupal removes the destination=.. parameter from the URL, but language=.. is kept in it, which results in no filtering occurring.

Anything that can be done about that? I wasn't able to find the place in the code where this is happening I'm afraid.

Cheers

[Meta] Discuss how to merge new modules into core

Issues: nod_@drupal -

This summer I'm likely going to be working on #229568: Include Pathauto in Core and I'm seeing several options for how I can propose merging Pathauto (or other potential modules) into core.

  1. Lieutenant model: This is my preferred option. Pathauto would continue to "live" in contrib and would be "bundled" in the core repository from the 8.x-1.x branch. Is this possible it all (maybe using git sub-modules)? If so what changes would we need to make to have this possible? It was brought up at Dries' core conversation in Denver but it hasn't really been discussed since then.
  2. Normal merge: When we merge modules into core there can be two different ways it can be done.
    1. Enhancement: Merge into an existing core module, for example, merge Pathauto with path.module. How does this work if someone wants to turn off automatic aliasing (or whatever feature the merged module adds)?
    2. Add as-is: This would copy/paste all of Pathauto's files into core/modules/pathauto and if approved enable Pathauto as part of the standard install.

I would first just like to really discuss if the Lieutenant model is possible, feasible, and something that Dries/catch would agree to doing because that is highly my preferred option. I just don't want to waste my time attempting to merge in Pathauto if it's not going to be a plan that I don't agree with.

Regardless of how it is merged in, we would continue to probably use a core fork sandbox and provide patches based on diffs of that sandbox compared to 8.x.

drupal_html_id() broken for forms with file element

Issues: nod_@drupal -

Currently when form has file element there's no ability to send ajax_html_ids because it's not possible to serialize that array to send with jQuery Form plugin shipped with core.

Also ajax_html_ids has array structure that makes ajax requests take more bandwidth by prefixing each value with

ajax_html_ids[]

.

Proposed solution

Send ajax_html_ids serialized imploded with space because HTML5 standard does not limits allowed characters for HTML IDs except 'white-space'.

The ajax_page_state already has plain structure so this is some kind of standardization for ajax variables.

Also this change help to minimize request size for ajax calls as discussed in #956186: Ensure it is possible to use AJAX with GET requests

Testing troubles

Currently simpletest has no ability to test ajax request properly so only manual testing possible.

Steps to reproduce

- download and enable attached module (ajaxdemo)

- visit /ajaxdemo_test_html_ids and press Get
-- bellow will output count and list of used IDs (they are passed as array)

- visit ajaxdemo_test_html_ids/1 and press Get (file element should appear on form)
-- there would be only one element serialized with ',' (in this case core can't extract IDs used on page)

Rewrite tableheader.js

Issues: nod_@drupal -

tableheader has several problems:

  • complicated computation during the onscroll event
  • hard to extend for contrib
  • messy HTML

What I'd like to see is:

  1. No computation during scroll, listen to a custom event for updating the offset value
  2. initialize tableheader on first scroll, not on page load.
  3. Offload all offset computation to the modules adding the elements, (toolbar)
  4. use data- attributes to store and get offsets
  5. Only initialize tableheader for table longer than half screen space available (or something), tableheader is not useful for small tables (like the attached files table in issues…)
  6. (bonus) try to get rid of the extra table by playing with the original <thead>

With that we should be able to remove to reduce tableheader footprint quite a lot.

Clean-up: batch.js

Issues: nod_@drupal -

Removed the scoped .find() an ID is unique on a page and doesn't need to be scoped.
Added the Drupal object to the closure like we're doing with the jQuery object (see #1089300-5: clean up drupal.js)
removed the closure in .once() instead we check that .once() returned an element and process it.
Changed the name of progress to progressBar to avoid confusion with the new $progress variable.

AttachmentSizeStatusTest resultOperations core-js-selectors-batch.patch1.31 KBIdlePASSED: [[SimpleTest]]: [MySQL] 36,577 pass(es).View details | Re-test

Selectors clean-up: authorize.js

Issues: nod_@drupal -

Selectors are not repeated.
Removed duplicated code.
Removed .length check, jQuery can deal with empty results gracefully.

I'm not quite sure how to get this file included so that I can test nothing broke. If you can tell me how to test that would be nice.

I'd like to remove the float thing and make js add/remove a class name, that'd be cleaner. I'm not sure we want the JS script to add a "no-float" class or remove a "float-left" class that would be added on the PHP side.

AttachmentSizeStatusTest resultOperations core-js-selectors-authorize.patch1.43 KBIgnored: Check issue status.NoneNone

Selectors clean-up

Issues: nod_@drupal -

We agreed on a few things in the jQuery issue #1541860: Reduce dependency on jQuery This is the meta tracking the progress. What this aims at is a full review of our JS code.

What we agree on, in order of most important for perfs:

  1. #1279226: jQuery and Drupal JavaScript libraries and settings are output even when no JS is added to the page
  2. Look at all our selectors and HTML structure and see how that can be simplified to allow better, faster selectors.
  3. using querySelectorAll when sizzle-specific selectors are not needed.
  4. use regular for loops when $(seletor).each() is overkill.

The plan is to open an issue for each core file/module and tackle points 2-4 one file at a time.

ajax.js [#] authorize.js [#] autocomplete.js [#] batch.js [#] collapse.js [#] drupal.js [#] form.js [#] machine-name.js [#] progress.js [#] states.js [#] tabledrag.js #1524414: Rewrite tabledrag.js tableheader.js [#] tableselect.js [#] timezone.js [#] vertical-tabs.js [#] block [#] book [#] color [#] comment [#] contextual [#] dashboard [#] field/modules/text [#] field_ui [#] file [#] filter [#] locale [#] menu [#] node [#] openid [#] overlay [#] shortcut [#] simpletest [#] statistics [#] system [#] taxonomy [#] toolbar [#] user [#] themes/bartik/color [#]

I've highlighted the ones that would benefit the most. The changes to tabledrag are a bit more drastic than the rest so we might to keep it for the end since it's such a big piece of code.

Feel free to edit and add links to issues. Don't forget to add the "JavaScript Clean-up" tag to every issue you might open for this.

Load your theme during preview?...

Issues: nod_@drupal -

Hi,

I know your busy working on more important issues and I hope this could be an easy reply. Don't know where to post this, but I'm using "Display Suite" to layout my Articles. When editing or creating: how do I get my theme .css to load during preview?

Not sure if the theme I'm using has anything to with it not being used at this time.

Thanks!...

Pages

Subscribe to theodoreb aggregator