Filter order no longer respected

1. +++ b/core/modules/filter/filter.module
   @@ -401,7 +401,7 @@ function check_markup($text, $format_id = NULL, $langcode = '', $cache = FALSE,
   -  $filters = $format->filters();
   +  $filters = $format->filters()->sort();
   

   Unless there is a very good reason for why we cannot, filters() (FilterBag) should return the sorted filters already.

   We should prevent anyone from operating on unsorted filters.

2. +++ b/core/modules/filter/lib/Drupal/filter/Tests/FilterAPITest.php
   @@ -68,7 +68,37 @@ function setUp() {
   +          'status' => -10,
   

   weight?

Hmm, FilterFormat::preSave() sorts the filters, I would have thought that would take care of it.

If you call $format->filters(), it gives you the bag with the filters uninitialized. That way you can check things like ->has('filter_html') quickly.
sort() always initializes all of the plugins.

But if you're about to loop over them anyway, you don't really care...

They can be sorted on init and still sorted again on save, but not on every retrieval.

Hah! That test is actually wrong. The order of the value returned by getFilterTypes does not actually matter, but in HEAD it was unsorted, and the test was asserting based on that order. Now that we're sorting them, the type of the filter with weight -10 comes before the -1 filter.

I have the exact same problem with Drupal 7.26.
Is there a fix, too?

The PHP-Evaluator should come before the "GMap Macro expander". The order is correct set in admin/config/content/formats/php_code but it doesn't work.

Awesome - that looks much better + secure now, thanks! :-)

vegi: Hm. Doesn't sound related, since this is D8-specific code. Maybe open a separate 7.x issue to discuss?

I needed to add a comment to this prior to commit, because I had no idea what "crazy" means in this context. It doesn't feel overly crazy to me to strip out invalid HTML prior to escaping angle brackets. (I guess you meant it's crazy to say that llamas are not awesome, but then I'd call that variable "$crazy_text" instead.)

Though I'm all for silliness, in this case I think it might be an example of us being a little too silly, to the detriment of the next poor person to read/debug this code. :) Not really a reason to hold up a critical, though.

Anyway, extended the description with this:

    // Create crazy HTML format, which strips out disallowed tags prior to
    // escaping HTML.

And committed/pushed to 8.x. Thanks!