Use '#wysiwyg' => FALSE and remove _pathauto_warn_wysiwygs()

6.x-1.x is missing the removal of the warning function. Do most of these modules actually respect the "#wysiwyg false" attribute?

Also, I'm fine if we stop maintaining the 6.x-2.x branch. We should make 7.x the home for the fun stuff and 6.x-1.x the stable thing.

I think we should rather get a 6.x-2.0 out the door and let 6.x-1.x slowly die out. Regardless of new features in 7.x-1.x, 6.x-2.x will still smooth the transition from 6.x-1.x to 7.x-1.x.

Also, I like this issue. :)

How does it smooth the transition? For coders or for end users?

The proper solution for this issue is to

1) kill this entire warning, do NOT implement the #wysiwyg property

2) won't fix any bug report/support request against Pathauto regarding editors

The presumption is wrong: A proper and respectful editor integration will not hi-jack Pathauto's form at all. Period.

While marking issues won't fix, you can point users to Wysiwyg module (and perhaps others, if they are equally smart).

[04:41] tha_sun: I feel totally guilty for introducing that #wysiwyg property idea in the first place. Shit happens to ill ideas. All over again
[04:42] tha_sun: davereid: their fault
[04:43] tha_sun: No one should support a wrong concept
[04:43] Ok, what is wrong with it?
[04:43] tha_sun: Client-side editors can only work on input fields for filtered content
[04:44] tha_sun: It makes zero sense to bootstrap an editor on any form element that doesn't support HTML
[04:45] tha_sun: So Pathauto is babysitting broken code
[04:46] tha_sun: If people need to use those other editor integration modules, then those other editor integration modules can happily copy+paste Wysiwyg's code

At your service.

So Pathauto is babysitting broken code

Yes, exactly. And, either we babysit in code or we babysit in the issue queue. It is a major pain to babysit the issue queue so I put this into the code. Even so we still get bug reports about it in the queue. So, #14 is a won't fix IMO.

I like the strip_tags idea. And then we would show the message if the strip_tags version differs? Seems great to me.

-1 That strip_tags() idea won't work, and I'm not entirely sure where those ignored words would be displayed. You don't want to confuse users more by putting those words into the regular configuration form elements, right? A hidden/invisible/disabled textarea will usually not trigger and load an editor.

Instead of increasing the superfluous code to babysit broken modules, it should be decreased.

If you absolutely want to, then you can surely add #wysiwyg => FALSE and just pray that every other module out there properly supports it.

Double post?

You could however, try an insane validator applied as #element_validate to all fields:

function pathauto_admin_element_validate_plaintext($element, &$form_state) {
  if (strip_tags($element['#value']) != $element['#value']) {
    form_error($element, t('Client-side editors are not supported here. Please change your configuration or switch to a proper module.'));
  }
}

However, still --- overall, I don't see why Pathauto should special-case all of this. There are 4,000+ other modules out there. Do we really want to add this babysitting cruft to every module out there? No. And so shouldn't Pathauto.

FWIW, I'm leaning towards the approach in #14, followed up by "won't fix"'es to issues, complaining about them using a bad WYSIWYG module. Especially now that Dave is so active in the queue as well - between the 3+ of us, the WYSIWYG issues that would crop up, shouldn't be too taxing.

@sun - the idea you propose in #20 is exactly in line with what Dave was proposing.

I think we should do #14 and #20 (aka #16).

Just being pedantic, but

-  _pathauto_include();
+  module_load_include('inc', 'pathauto');

should probably be its own patch. :)

Looks great to me.