TableSort Plugin - Yaml Issue

Hi There;
I have started to use Grav as personal website. I have been struggling for adding some widget options into tablesort plug in. Since I am new into grav, I am not sure that if the issue is grav related or the plugin. But for me it seems like it is grav related. So I am writing in here.

The problem is: I want to configure plugin in admin page, with the frontmatter.
I have added following configs and it works fine as excepted.

    active: true
    include_widgets: true
    themes: metro-dark
                - zebra
                - filter
                - widget-filter-formatter-select2
                        - foo
                        - yoo
                filter_reset: button.reset
                filter_saveFilters: true
                    input: match
                    select: match
                    - 0
                    - 0

The problem start when I try to add setting for widget-filter-formatter-select2 function. I have to add key:value into widget options. But when I type in console and save, my key:value input is reformated into a list type.

     0: function(){}
     1: function(){}

Reformated into:

     - function(){}
     - function(){}

Which is wrongs for the function and does not work.

Also I have tried editing file from console, but the arguments still parsed into wrong way.

I have also tried some non-sense key:value for testing purposes, and they were all turned into list.

Does anyone has a suggestion. Where should I look into?

I have solved the problem.

The problem was with the yaml parser in grav. If the first element is “0” it parses as list instead of dictionary.

Great that you solved this.

I’m inclined to regard it as a bug. Would you consider this a bug or a feature?

1 Like

This is definitely a bug. It may not effect majority of people use. But for my case, jquery Tablesorter plugin turn yaml config into js function. This is why the output type of yaml config was so important.

Here are some examples for more depth information.

     - foo
     - bar

parsed into ABC=[“foo”, “bar”] as intended.

     0: foo
     1: bar

parsed into ABC=[“foo”, “bar”] which is a bug. It should be ABC={0: “foo”, 1: “bar”}

     1: bar
     0: foo

parsed into ABC={1: “bar”, 0: “foo”} which is correct.

With my investigation, the problem only occurs when the first element of yaml dictionary is “0”.

Beside this issue , I have another problem with yaml parse. But this time it is not bug. In order to use some feautures of tablesorter I have to pass one line functions as parameter.

         1: function multiTwo(x){ return 2*x; }

The problem starts when yaml parser turns my input into:
filter_formatter = {1: "function multiTwo(x){ return 2*x; }"}

Which is correct for parser perspective in Grav. But for my case it is useless. Since whole function is parsed as string.

if there is a special format for passing js function with yaml will make thinks easy for using lots of options in plugin like tablesorter.

For now, I had writen whole table sorter config function from scratch for my use case to use some options i would like to.

@selamet, I’ve been pondering on this issue, especially because of the nature of PHP’s associative arrays.


  1. All Yaml structures (map, sequence) are parsed into associative arrays. A Yaml sequence and Yaml map with numbers yield the same result.
    This means it is not a Grav issue/bug, but rather caused by the nature of PHP arrays.
  2. Plugin ‘grav-plugin-tablesorter’ could address this.
  3. jQuery.tablesorter and all scripts, css, options can be added by page using Twig.
    I guess this will also solve the ‘function’ issue.

Ad 1.
Grav uses the Yaml parser from Symfony, so I did some tests with Symfony, outside of Grav, to see how Yaml is parsed into PHP structures.

I ran the following test to see how Yaml is parsed into php:

function parseYaml() {
    $yaml = <<<'YAML'

# A Yaml sequence
  - zero
  - one

# A Yaml map with integers as keys
  0: zero
  1: one

# A Yaml map with integers as keys not starting with 0
  22: two
  33: three

# A Yaml map with strings as keys containing integers
  '22': two
  '33': three


With the following output:

array (size=4)
  'sequence' => 
    array (size=2)                      <----+
      0 => string 'zero' (length=4)          |
      1 => string 'one' (length=3)           |  Same result
  'map-with-integer-keys-0-based' =>         |
    array (size=2)                      <----+
      0 => string 'zero' (length=4)
      1 => string 'one' (length=3)
  'map-with-integer-keys-any-number' => 
    array (size=2)
      22 => string 'two' (length=3)
      33 => string 'three' (length=5)
  'map-with-string-keys-containing-integers' => 
    array (size=2)
      22 => string 'two' (length=3)
      33 => string 'three' (length=5)

Ad 3.
How to enable jQuery.tablesorter in Markdown?

title: Typography
    twig: true
cache_enable: false  # cache must be turned of for this page

<table id="id1" class="tablesorter">

{% do assets.addJs('') %}
{% do assets.addJs('') %}

{% do assets.addCss('') %}

    $("#id1").tablesorter({theme: 'blue'});

Altenatively, you could create your own Twig template for pages containing a table.

1 Like

@pamtbaau Thanks for detailed information about the issue. Now I understand what was going on at background.

With your answer, It turns out the issue is more related with Symfony and PHP datatypes.

I am not familiar with PHP nor Javascript. But as a developer the behavior with the parser seems odd. To figure out, I have to read tons of documents and tried lots of alternative. Maybe for those who has PHP background does not struggled as much as I do.

Anyway It was a good experience for myself. We are improving ourself when we get stuck.

Actually this is not very PHP language related. It’s more about the difference between indexed or numeric arrays and associative arrays. PHP and YAML both support the two types.

The problem lies in that while converting a PHP indexed array to YAML it is unknown what format is desired: a sequence or a mapping (as @pamtbaau explained).

This issue has been discussed by Symfony developers as at first the conversion to a mapping had been implemented. Changing that behaviour would break existing applications and therefor the change was not approved. It was suggested to solve this with using a special flag to indicated the desired output format but that hasn’t been added either.