Sorting content without date

So I think I have run into an issue, that i am sure not how to resolve.

With this Github repo,

I have this file that I am feeding into here

           <div class="col-lg-6">
                <h3 class="text-dark mb-4 mt-5 mt-lg-0">Volunteer</h3>
                <ul class="timeline">
                    {% assign volunteer = site.data.resume.volunteer | sort: 'startdate'  | reverse %}
                    {% for workplace in volunteer %}
                    <li>
                        <h6 class="base-color mb-0">{{ workplace.company}}</h6>
                        <h7 class="base-color mb-0">{{ workplace.title }}</h7>
                        <div>
                            <small class="text-muted "> {{ workplace.startdate | date: "%B, %Y" }} - {% if workplace.enddate %} {{ workplace.enddate | date: "%B, %Y" }} {% else %} Present {% endif %}</small>
                        </div>
                        <p class="text-dark py-3"> {{ workplace.description }} </p>
                    </li>
                    {% endfor %}
                </ul>
            </div>

Now with the above, if I sort by startdate, any potential volunteer options that are still in progress, but, have older start dates, will not show up as being recent. The answer to this is to solve by “enddate”.

But, let’s say I have a entry in the yml file that does not have an “enddate” because it is currently being employed, I would have to add an if statement there to say if not present, add “present”. However, if I sort on enddate, it will list that entry as the last entry.

What is the best way to get around this issue?

I think sorting in general goes like this

'' 
'1'
'11'
'a'
'aa'
'b'

ie empty string first, then numbers and then letters. So your ‘present’ will come after and YYYY MM DD values.

What happens if you use sort_natural instead of sort. It might not as it works on case but try anyway.

Or, set enddate as an empty string whenever you mean present. and then use sort or sort natural on enddate.

I say empty string rather than leave out the key because I think sort will give an error of the key is missing or value is null.

And then you can turn empty string into Present or present on the presentation layer.

Otherwise you can try make two arrays. One filtered to enddate is set and other where it is not set and sorted the one where it is set.

Then combine them into one array with the empty enddate array first

So I tried adding a blank entry by adding “” to the enddate: under Line 27 of the resume.yml file.

I also modified to the following:
<small class="text-muted "> {{ workplace.startdate | date: "%B, %Y" }} - {% if workplace.enddate == nil or workplace.enddate == "" or workplace.enddate == blank %} Present {% else %} {{ workplace.enddate | date: "%B, %Y"}} {% endif %}</small>

(Doesn’t really matter if I am working on Volunteer, Education, or Work, they basically all have the same code, just using different variables)

You can see the changes in commit f5167d9

Unfortunately, it still sorts the blank entry to the bottom (when I use the reverse). sort_natural does not seem to make a difference.I guess going forward, it seems like the only. So it looks like creating two arrays is the only way to move forward. I was hoping that there was a more graceful way to accomplish that.

So I guess the best way to accomplish this to split, sort, and then concatenate would be something along the lines of this?

| group_by_exp: "workplace", "workplace.enddate == nil or workplace.enddate == '' or workplace.enddate == blank:
Or would it be better to use where filter?

Using where_exp, and the and and or operators solved the issue of the topic:

{% assign previouswork = site.data.resume.work | where_exp:"entry", "entry.enddate != nil and entry.enddate != blank and entry.enddate != ''" |  sort: 'enddate' | reverse %}
                    {% assign currentwork = site.data.resume.work | where_exp:"entry", "entry.enddate == nil or entry.enddate == blank or entry.enddate == ''" |  sort: 'startdate' | reverse %}
                    {% assign work = currentwork | concat: previouswork %}
                    {% for workplace in work %}
                    <li>
                        <h6 class="base-color mb-0">{{ workplace.company}}</h6>
                        <h7 class="base-color mb-0">{{ workplace.title }}</h7>
                        <div>
                            <small class="text-muted "> {{ workplace.startdate | date: "%B, %Y" }} - {% if workplace.enddate == nil or workplace.enddate == "" or workplace.enddate == blank %} Present {% else %} {{ workplace.enddate | date: "%B, %Y"}} {% endif %}</small>
                        </div>
                        <p class="text-dark py-3"> {{ workplace.description }} </p>
                    </li>
                    {% endfor %}

Be aware this have caused the page to fail to build due to Github Pages using jekyll=3.9.0. Read further down for resolution on that.

Well, I have done something, but, I am not sure what exactly is causing this:

Seems like pages is failing to publish, but there is not any descriptive error there. So I don’t know what is going on.
I installed 3.9.0 locally and started running build --trace, and fount out that this is the issue:

$ bundle exec jekyll build --trace
Configuration file: /mnt/c/Users/Andrew/Documents/Github/delize.github.io/_config.yml
            Source: /mnt/c/Users/Andrew/Documents/Github/delize.github.io
       Destination: /mnt/c/Users/Andrew/Documents/Github/delize.github.io/_site
 Incremental build: disabled. Enable with --incremental
      Generating...
       Jekyll Feed: Generating feed for posts
  Liquid Exception: Liquid syntax error (/mnt/c/Users/Andrew/Documents/Github/delize.github.io/_includes/page-resume.html line 9): Expected end_of_string but found id included in /_layouts/page.html
bundler: failed to load command: jekyll (/home/andrew/gems/bin/jekyll)
Liquid::SyntaxError: Liquid syntax error (/mnt/c/Users/Andrew/Documents/Github/delize.github.io/_includes/page-resume.html line 9): Expected end_of_string but found id included
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/parser.rb:16:in `consume'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/filters.rb:369:in `parse_condition'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/filters.rb:200:in `where_exp'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/strainer.rb:56:in `invoke'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/context.rb:86:in `invoke'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/variable.rb:84:in `block in render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/variable.rb:82:in `each'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/variable.rb:82:in `inject'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/variable.rb:82:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/tags/assign.rb:26:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:103:in `render_node_to_output'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:91:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:208:in `block in render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:242:in `with_profiling'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:207:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:220:in `render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:30:in `block (2 levels) in render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:42:in `measure_bytes'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:29:in `block in render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:49:in `measure_time'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:28:in `render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/tags/include.rb:140:in `block in render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/context.rb:123:in `stack'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/tags/include.rb:137:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:103:in `render_node_to_output'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/block_body.rb:91:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:208:in `block in render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:242:in `with_profiling'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:207:in `render'
  /home/andrew/gems/gems/liquid-4.0.3/lib/liquid/template.rb:220:in `render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:30:in `block (2 levels) in render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:42:in `measure_bytes'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:29:in `block in render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:49:in `measure_time'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/liquid_renderer/file.rb:28:in `render!'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/renderer.rb:126:in `render_liquid'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/renderer.rb:195:in `render_layout'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/renderer.rb:158:in `place_in_layouts'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/renderer.rb:88:in `render_document'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/renderer.rb:62:in `run'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:479:in `render_regenerated'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:472:in `block in render_pages'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:471:in `each'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:471:in `render_pages'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:192:in `render'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/site.rb:71:in `process'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/command.rb:28:in `process_site'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/commands/build.rb:65:in `build'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/commands/build.rb:36:in `process'
  /home/andrew/gems/gems/jekyll-3.9.0/lib/jekyll/commands/build.rb:18:in `block (2 levels) in init_with_program'
  /home/andrew/gems/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
  /home/andrew/gems/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
  /home/andrew/gems/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
  /home/andrew/gems/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
  /home/andrew/gems/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
  /home/andrew/gems/gems/jekyll-3.9.0/exe/jekyll:15:in `<top (required)>'
  /home/andrew/gems/bin/jekyll:23:in `load'
  /home/andrew/gems/bin/jekyll:23:in `<top (required)>'

I am not sure I fully understand this error. The offending line is this:

{% assign previouswork = site.data.resume.work | where_exp:"entry", "entry.enddate != nil and entry.enddate != blank and entry.enddate != ''" |  sort: 'enddate' | reverse %}

The likely issue is that something is not supported in liquid or jekyll, and after a bit or research, it appears that is the case. :frowning:

Seems like it is supported in 4.0 > but not in 3.9.0 (for GitHub Pages).

So looking at this, what would be the best work around? Run several | where_exp: in place of the and or or? Or potentially just doing a Github Actions CI due to:

Not really sure one either side.

So I tried using a (similar) setup to your example here:

Unfortunately, as you can see:

Failures all day every day. After turning on debug, there is not a more beneficial explanation as to why it can’t push to master. I don’t think target branch should have to be specified, but, would that maybe help?

After doing some more research, it seems like this is the cause:

I guess, going forward - what is the best way to accomplish this. Cause at this point, I feel like I am having to do more and more to get this to work (rather than it being a bit more streamlined).

If I use jekyll-actions => 2.0.2, it seems like I have to create a Gemfile.lock versus the container just natively creating the file/pulling based on Gemfile for me. If I use jekyll-action @ 2.0.1, it works fine. I would assume that dynamically creating a Gemfile.lock on every build would be the better route of action, but I can also see why it is more beneficial to create your own and push.

Not sure what the best move here would be.

Can you stick to GH Pages but use simple logic? Use the fact that key not found and nil value and empty string are all falsy. And I would be consistent with present date - either always leave out the key or always leave it as empty string.

# has date
{% first_array = original | where_expr: item, item.enddate %}
# present day
{% second_array = original | where_expr: item, !item.enddate %}

Maybe not item.enddate instead of !item.enddate.

If you really need the OR conditions then just apply like this as a series of ANDs.

{% first_array = original 
  | where_expr: item, item.enddate != nil 
  | where_expr: item, item.enddate != ''
  | sort: 'enddate'
  | reverse
%}

{% second_array = original 
  | where_expr: item, item.enddate == nil 
  | where_expr: item, item.enddate == ''
%}

Then hopefully you can stay on GH Pages.

Once you have the two arrays, I don’t know how to join them but here is a way to skip joining them. Use two for loops and move your common logic to excludes.

<ul>
{% for job in second_array %}
{% include render.html job=job %}
{% endfor %}

{% for job in first_array %}
{% include render.html job=job %}
{% endfor %}
</li>

And the includes. Assuming each job item has these keys. The item passed above is available as include.item here.

_includes/render.html

<li>
  Title: {{ include.job.title }} End date: {{ include.job.enddate | default: 'present' }}
</li>

Hm I tried your suggestions:

With the and route, it doesn’t work as expected, I think this is because you are piping multiple where_expr every time, where I am attempting to run a single where_expr with multiple and/or statements.

Unfortunately with the OR route you have listed, every time I am presented with

/home/andrew/gems/gems/liquid-4.0.3/lib/liquid/lexer.rb:25:in `initialize': no implicit conversion of nil into String (TypeError)

This does not seem to work. :confused:

I might just have to update to 2.0.4 jekyll-actions and include a lock file. I found out that with 2.0.1, jekyll-actions doesn’t consider the Jekyll environment production, and doesn’t output content properly.