In D7 if pathauto wants to override the 'Path' fieldset summary, there is no solution for this currently.

Comments

Dave Reid’s picture

Title: Impossible to override a vertical tabs summary JS » Difficult to override a vertical tabs summary JS

I guess it's not 'impossible' per say, but since in D7 we can have an unlimited number of attached JS files on an element. How does Pathauto know which one is the vertical tabs summary and be easily able to replace it with its own JS.

Like I tried to explain in #625814: Move vertical tabs integration for Flag into flag.module my best solution is to always give the vertical tabs resposible JavaScript a 'vertical-tabs' key in the #attached array.

So instead of:

function path_form_alter(&$form, $form_state, $form_id) {
  if (!empty($form['#node_edit_form'])) {
    ...
    $form['path'] = array(
      '#type' => 'fieldset',
      ...
      '#attached' => array(
        'js' => array(drupal_get_path('module', 'path') . '/path.js'),
      ),
      ...
    );

We do:

function path_form_alter(&$form, $form_state, $form_id) {
  if (!empty($form['#node_edit_form'])) {
    ...
    $form['path'] = array(
      '#type' => 'fieldset',
      ...
      '#attached' => array(
        'js' => array(
          'vertical-tabs' => drupal_get_path('module', 'path') . '/path.js',
        ),
      ),
      ...
    );

That way any other module (like pathauto) can easily do this:

function pathauto_form_alter(&$form, $form_state, $form_id) {
  if (!empty($form['#node_edit_form'])) {
      ...
      // Override path.module's vertical tabs summary.
      $form['path']['#attached']['js']['vertical-tabs'] = drupal_get_path('module', 'pathauto') . '/pathauto.js';

Maybe we should allow multiple JS functions to override each other instead of having to replace the JS. I'm open to ideas.

dmitrig01’s picture

You can override JS functions. Why not just override Drupal.behaviors.pathFieldsetSummaries?

Drupal.behaviors.pathFieldsetSummaries = {
  attach: function (context) {
    $('fieldset#edit-path', context).drupalSetSummary(function (context) {
      // Custom stuff here.
      return 'foo';
    });
  }
};

Just make sure that is included after the main path.js. Tempted to mark by design but won't yet

sun’s picture

As long as you have a separate (entire) behavior for each summary, overriding the entire JS function is doable.

However, most summaries are buried deeply into other behavior code, or multiple summaries are stacked into the same behavior. Overriding those, in a modular system like Drupal, is technically impossible.

Ideally, we'd have one Drupal.summaries.moduleNameFieldName function per summary that can easily be overridden.

dmitrig01’s picture

Hm, as a layer on top of .drupalSetSummary?

sun’s picture

I also don't have a clue yet. Playing live:

Drupal.fieldsetSummary.pathAlias = function (context) {
  $('fieldset#edit-path', context).drupalSetSummary(function (context) {
    // Custom stuff here.
    return 'foo';
  });
};
...

Drupal.behaviors.fieldsetSummary = {
  attach: function (context) {
    $.each(Drupal.fieldsetSummary, function () {
      this(context);
    });
  }
};

That would surely be the simplest way to split them.

More?

Drupal.fieldsetSummary.pathAlias = {
  selector: 'fieldset#edit-path',

  setSummary: function (context) {
    // Custom stuff here.
    return 'foo';
  }
};
...

Drupal.behaviors.fieldsetSummary = {
  attach: function (context) {
    $.each(Drupal.fieldsetSummary, function () {
      $(this.selector, context).drupalSetSummary(this.setSummary);
    });
  }
};

I kinda like that one, if it's doable.

sun’s picture

Priority: Normal » Major
sun’s picture

Priority: Major » Normal

Oops, wrong issue... anyway, any feedback? Current situation is really bad for modularity.

nod_’s picture

Version: 7.x-dev » 8.x-dev
Component: base system » javascript
Assigned: Dave Reid » Unassigned

The summary thing does wierd and wrong things, needs to be refactored. #5 is not ideal (since it's a working around summary) but would work.

droplet’s picture

I just come up same idea. We have 22 usages in CORE, sharing same pattern of code.

e.g.

    $context.find('fieldset#edit-submission').drupalSetSummary(function(context) {
      var vals = [];
      vals.push(Drupal.checkPlain($(context).find('#edit-title-label').val()) || Drupal.t('Requires a title'));
      return vals.join(', ');
    });

- target selector
- decide to show label text or a custom text

I hope it convert to something like:

$target.drupalSetSummary({
	'.form-item-revision input' : {
		rule: ':check',
		validMessage: 'Published',
		invalidMessage: 'Not Published'
	},
	'.form-item-node-type-language-default select option' : {
		rule: ':selected',
		validMessage: null, // Default message, find label texts
		invalidMessage: null, // Default message, find label texts
	},
});

config able to read from Drupal.settings. also make FORM API to eat these params.

nod_’s picture

Status: Active » Closed (duplicate)