rakefire / jekyll-ical-tag Goto Github PK

View Code? Open in Web Editor NEW

7.0 7.0 5.0 145 KB

Pull ICS feed and provide a for-like loop of calendar events in jekyll's liquid tag

Ruby 99.55% Shell 0.45%

jekyll-ical-tag's People

Contributors

Stargazers

Watchers

Forkers

nodevel fabacab adamblan c-leitner

jekyll-ical-tag's Issues

Cannot dereference iterator variable inside `for` loop: `KeyError` is raised

Although dereferencing directly into page variable (page.icalendar_url, for instance), the same does not work when this is put inside of a {% for %} loop. The following example template code:

{% for cal in site.calendars %}
{% ical url: cal.icalendar_url %}{% endical %}
{% endfor %}

raises a KeyError. The jekyll build --trace output ends with:

lib/jekyll-ical-tag.rb:127:in `fetch': key not found: :cal (KeyError)

Undefined method error when a VEVENT component includes a DESCRIPTION with some IRIs

Hi again. I noticed a new issue with certain iCalendar feeds that I'm having difficulty troubleshooting because of my lack of Ruby skill. The error is consistent and happens during a jekyll build for me:

Liquid Exception: undefined method `force_encoding' for #<Icalendar::Values::Array:0x00007fb0623e7528> in /_layouts/calendars.html
jekyll 3.9.0 | Error:  undefined method `force_encoding' for #<Icalendar::Values::Array:0x00007fb0623e7528>

I've attached a copy of the iCalendar file (serenoregis.ical.txt) causing the issue. It was sourced from an Italian Web site's event calendar feed.

The issue seems to be on line 69 of event.rb, where the description variable remains of type Icalendar::Values::Array despite its conversion to a string.

There are three VEVENT components in the attached copy of the feed, but only one of them (the last of the three) is causing the error. It's also worth noting that it's also the only VEVENT component with a URL in the DESCRIPTION property, triggering the regex to match URLs and thus the relevant description_urls method.

Despite tracing this down in this way, I'm unsure what a good resolution would be so I'm opening this issue to ask for your advice on how to patch.

Possible regression in v1.2.5: `only_future` limiter no longer omits past events from iCalendar feed result

In versions prior to v1.2.5, the only_future argument to the ical for loop tag caused VEVENT components whose DTSTART attribute were understood to be prior to the time returned by site.time to be omitted from the loop. Starting in v1.2.5, all VEVENTs are included in the loop regardless of this argument (or the limit argument). For example:

{% ical url: ical_url only_future: true limit: 1 %}
* {{ event.summary }}
{% endical %}
{% comment %}
Only the single next-most event, based on the value of `site.time`
should be in the prior loop. Instead, *all* VEVENT components in the given feed
at `ical_url` are returned and the loop prints all of them.
{% endcomment %}

Error when using page variables (`TypeError: Jekyll::Drops::DocumentDrop does not have #dig method`)

First, sorry for having just said everything was kosher and then finding this bug immediately after. Turns out the minute I tried to use a page variable (which my templates were not doing yet; they were still doing {% assign url = page.some_var %}{% ical url: url %}…), I get the error quoted in the title.

Template code like this:

{% ical url: page.some_var %}{% endical %}

fails to build with the following exception:

$ bundle exec jekyll server --future
[…]
  Liquid Exception: Jekyll::Drops::DocumentDrop does not have #dig method in /_layouts/calendars.html
jekyll 3.8.5 | Error:  Jekyll::Drops::DocumentDrop does not have #dig method

A bundle exec jekyll build --trace points precisely to the error, described here.

The issue arises from lack of support for Hash#dig in Jekyll::Drops::DocumentDrop, which is what a call to, e.g., context.registers.dig(:page) is actually returning. It doesn't return a plain Ruby Hash. This means any second argument specified at jekyll-ical-tag.rb line 123 will cause an error when the register is the :page or :site register, but works as expected in the one case of the most local ({% ical %}) scope.

I can find some time to code a solution at some point later this week but figured I'd report the issue immediately.

Liquid Exception: uninitialized constant Icalendar::Values::Array

Hi,

I get the following error when running bundle exec jekyll build (I've added a gemfile with gem 'jekyll-ical-tag' and bundle install works fine):

 Liquid Exception: uninitialized constant Icalendar::Values::Array in _pages/home.md
                    ------------------------------------------------
      Jekyll 4.2.1   Please append `--trace` to the `serve` command 
                     for any additional information or backtrace. 
                    ------------------------------------------------
 Traceback (most recent call last):
	68: from /Users/username/.rbenv/versions/2.7.2/bin/bundle:23:in `<main>'
	67: from /Users/username/.rbenv/versions/2.7.2/bin/bundle:23:in `load'
	66: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:37:in `<top (required)>'
	65: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
	64: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/exe/bundle:49:in `block in <top (required)>'
	63: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:24:in `start'
	62: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
	61: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:30:in `dispatch'
	60: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
	59: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
	58: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
	57: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli.rb:497:in `exec'
	56: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:28:in `run'
	55: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `kernel_load'
	54: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/bundler-2.2.3/lib/bundler/cli/exec.rb:63:in `load'
	53: from /Users/username/.rbenv/versions/2.7.2/bin/jekyll:23:in `<top (required)>'
	52: from /Users/username/.rbenv/versions/2.7.2/bin/jekyll:23:in `load'
	51: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/exe/jekyll:15:in `<top (required)>'
	50: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/mercenary-0.4.0/lib/mercenary.rb:21:in `program'
	49: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/mercenary-0.4.0/lib/mercenary/program.rb:44:in `go'
	48: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `execute'
	47: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `each'
	46: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/mercenary-0.4.0/lib/mercenary/command.rb:221:in `block in execute'
	45: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/commands/serve.rb:86:in `block (2 levels) in init_with_program'
	44: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/command.rb:91:in `process_with_graceful_fail'
	43: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/command.rb:91:in `each'
	42: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/command.rb:91:in `block in process_with_graceful_fail'
	41: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/commands/build.rb:36:in `process'
	40: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/commands/build.rb:65:in `build'
	39: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/command.rb:28:in `process_site'
	38: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:80:in `process'
	37: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:211:in `render'
	36: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:538:in `render_pages'
	35: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:538:in `each'
	34: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:539:in `block in render_pages'
	33: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/site.rb:547:in `render_regenerated'
	32: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/renderer.rb:63:in `run'
	31: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/renderer.rb:80:in `render_document'
	30: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/renderer.rb:131:in `render_liquid'
	29: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:36:in `render!'
	28: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:70:in `measure_time'
	27: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:37:in `block in render!'
	26: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:63:in `measure_bytes'
	25: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:38:in `block (2 levels) in render!'
	24: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:59:in `measure_counts'
	23: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-4.2.1/lib/jekyll/liquid_renderer/file.rb:39:in `block (3 levels) in render!'
	22: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/template.rb:218:in `render!'
	21: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/template.rb:205:in `render'
	20: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/template.rb:240:in `with_profiling'
	19: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/template.rb:206:in `block in render'
	18: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:82:in `render'
	17: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/block_body.rb:103:in `render_node_to_output'
	16: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag.rb:33:in `render'
	15: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/liquid-4.0.4/lib/liquid/context.rb:123:in `stack'
	14: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag.rb:43:in `block in render'
	13: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_feed_coordinator.rb:17:in `events'
	12: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_limiter.rb:37:in `events'
	11: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_limiter.rb:37:in `events'
	10: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_limiter.rb:37:in `events'
	 9: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_limiter.rb:25:in `events'
	 8: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_limiter.rb:16:in `events'
	 7: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_parser.rb:16:in `events'
	 6: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_parser.rb:16:in `map'
	 5: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_parser.rb:16:in `block in events'
	 4: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/calendar_parser.rb:16:in `new'
	 3: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/event.rb:34:in `initialize'
	 2: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/event.rb:80:in `setup_all_properties!'
	 1: from /Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/event.rb:80:in `transform_values!'
/Users/username/.rbenv/versions/2.7.2/lib/ruby/gems/2.7.0/gems/jekyll-ical-tag-1.4.0/lib/jekyll-ical-tag/event.rb:83:in `block in setup_all_properties!': uninitialized constant Icalendar::Values::Array (NameError)

Proposal: Use RFC5545 attribute names for events

Would you have any interest in supporting a patch (that I am willing to code myself) that would make it possible to reference event attribute data by its standard RFC5545 object property names?

I ask this because I have several instances of Jekyll templates that rely on standardized naming schemes for event-like objects, and it becomes difficult to maintain generalized templates when different utilities use different names to expose the data they provide.

There is an underlying standard from which all this data is generated, of course: RFC 5545, the iCalendar specifiction. This specification provides an exhaustive listing of all legal iCalendar property names that are, in my experience, more than satisfactorily self-describing and can be used to unambiguously refer to specific data that a consuming application wants to inspect.

Before I actually do this work, though, I would love to know whether or not this is something you would be willing to merge and then support. My plan would be to alias the current attribute names (start_time) to the standard property names (dtstart) so as not to break backwards-compatibility, but to suggest that non-standard attribute names be formally deprecated moving forward.

Such a change would make it possible to reuse Jekyll template includes that produce, for example, h-calendar compliant microformat markup in a manner such as:

{% ical url: https://example.com/events.ics %}
    {% include h-event.html event=event %}
{% endical %}

where h-event.html contains generalized iCalendar-aware template code such as:

<div class="h-event vevent">
[…]
<p><time datetime="{{ include.event.dtstart | date_to_xmlschema }}">{{ include.event.dtstart | date: site.datetime_format }}</time></p>
[…]
</div>

instead of checking for provider-specific attribute names.

Some attributes in this plugin already provide the RFC 5545 object property names, e.g., summary. However, others do not. I would like to propose that all attributes of an event exposed by this Gem conform to the same RFC 5545 standard naming scheme.

Thanks in advance for the wonderful Gem, regardless. :)

reverse: flag does not reverse order.

Using an ICS link from Sesh (https://sesh.fyi/calendar/98AtNsUKcpeFsCGzc8Zeie.ics for reference) where start time is indeed unique for multiple events the reverse flag in the ical plugin does not actually reverse the order of the posts.

`pry` Gem is included in production builds by default

Is pry really necessary for a production build, or can it be limited to development only? See line 37 of jekyll-ical-tag.gemspec. I'm not certain one way or another but just noticed my build logs still including this Gem on my servers, and if my understanding of pry as a debugger/repl is correct, then it should probably not be on a production machine, yes?

Package not updated on rubygems.org

It seams like that the package has not be updated on rubygems.org https://rubygems.org/gems/jekyll-ical-tag/

Printing `event.excerpt` sometimes produces a string, other times an array depending on event data

Similar to what's described in #25, when trying to print a given event's excerpt (as opposed to its content or description), which I believe is a member property automatically generated by part of Jekyll core, templates don't always produce expected results. Specifically, in the exact same situations as described in the issue cited earlier, printing an event.excerpt from within an ical tag loop will print an array, complete with square brackets (["content of excerpt…") rather than the simple string as expected. For example, with the Sereno Regis test iCalendar file:

{% ical url: https://github.com/Rakefire/jekyll-ical-tag/raw/master/spec/support/serenoregis.ics %}
* {{ event.excerpt }}
{% endical %}

produces HTML, in part, like this:

<li>[“Il 29 novembre \xC3\xA8 una data importante per il popolo Palestinese. \nIn questa data nel 1947, l\xE2\x80\x99Assemblea Generale delle Nazioni Unite adott\xC3\xB2 una risoluzione chiamata \xE2\x80\x9Cil piano di partizione\xE2\x80\x9D che divideva la Palestina in uno Stato Ebraico e uno Stato Arabo.\nA seguito di questa risoluzione, pi\xC3\xB9 di 700,000 Palestinesi scapparono…</li>

when the expected output should simply have been something more like:

<li>Il 29 novembre…</li> <!-- Etc., and encoded correctly. -->

Possible regression: `limit` argument no longer limits count of events in ical tag for loop

Following up quickly from #26 and likely related or similar to it is the fact that the limit argument in an {% ical … %} loop no longer seems to limit the count of events iterated over by the given loop. I.e., all events in the iCalendar feed URL are considered; the loop fails to break at the stated number of elements.

Liquid Exception: Liquid syntax error: unknown tag 'calendar'

Hi,
I got the Exception mentioned above while bundle exec jekyll serve.
I just copied your example code after doing the steps in the Readme.md

Greetings
Gilgamensch

Time changed to timezone of system.

I have encountered a weird issue. The timezone which is provided in the ical file is being recognized but the the output of the time is adjusted to the timezone of the system executing the program. I will check the possibility to add a attribute in the setup to select the output timezone. The issue appears because I am testing on a machine which is configured with GMT+2 but the code is being executed on a sever running with GMT and all the times are shifted by 2 hours.

Variables in Tag

I am not sure if it is possible but I can't get variable passing to work. I am trying to pass the "after_date:" as a variable.
{% ical url: https://example.com/test.ics reverse: false after_date: someVariableWithDate %}
When entering a date into the tag it works just fine, with a variable it does not work.
This would make it a lot easier to "dynamically" change the displayed output.