rakefire / jekyll-ical-tag Goto Github PK
View Code? Open in Web Editor NEWPull ICS feed and provide a for-like loop of calendar events in jekyll's liquid tag
Pull ICS feed and provide a for-like loop of calendar events in jekyll's liquid tag
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)
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.
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 VEVENT
s 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 %}
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.
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)
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. :)
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.
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?
It seams like that the package has not be updated on rubygems.org https://rubygems.org/gems/jekyll-ical-tag/
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. -->
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.
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
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.