NUKnightLab

In WordPress 6 you can use a “Custom HTML” block and drop in the iframe embed code from the Timeline site.

Of course, we understand that existing WordPress installs would prefer that their pages not “break”, and we’ll see if we can fix it… but

Also, the oembed feature enabled by the plugin still works, so you can include the URL to a timeline (such as https://cdn.knightlab.com/libs/timeline3/latest/embed/index.html?source=1xuY4upIooEeszZ_lCmeNx24eSFWe0rHe9ZdqH2xqVNk&font=Default&lang=en&initial_zoom=2&height=100% ) on a line by itself and it should work, although there’s less control over the dimensions of the embedded timeline.

Entered as an issue in GitHub

This is to verify that we have updated a test environment to WordPress 6.0.2 and the plugin no longer works for us either.

We will look into fixing it, but we don’t do a lot of active WordPress development so we welcome any suggestions people have about what might be the root issue.

Which mime types are used for files served by your system are outside of the control of TimelineJS. This is an issue for the server administrator.

excellent, that’s great to hear!

It looks as though you did not leave the ‘theme’ parameter on the page you shared before — I’m finding the iframe src URL to be
https://cdn.knightlab.com/libs/timeline3/latest/embed/index.html?source=1negtSiLRKM3lVnoIOQk113y6qDLOp3sidpV5HIPU7aI&font=Default&lang=en&initial_zoom=2&height=650

perhaps you added an attribute named theme to the iframe tag? The path is actually to add a theme parameter to the src URL.

Here’s an example of a URL which shows your timeline, but uses the “dark” timeline theme, which is mostly visible in the styling of the navigation area:

https://cdn.knightlab.com/libs/timeline3/latest/embed/index.html?source=1negtSiLRKM3lVnoIOQk113y6qDLOp3sidpV5HIPU7aI&font=Default&lang=en&initial_zoom=2&height=650&theme=https://cdn.knightlab.com/libs/timeline3/latest/css/themes/timeline.theme.dark.css

Another possible misinterpretation would be if you used a relative path to your CSS file (eg path/to/my/styles.css) — the path needs to be a fully qualified URL, since, when using iframe embeds, a relative URL would be interpreted as relative to cdn.knightlab.com, where you wouldn’t be able to put your theme CSS file.

does that help?

you are not using the timeline plugin to instantiate your timeline in your page; you’re using an iframe. That means anything you might do to CSS in the host page is not visible to the timeline.

Users of iframe embeds can pass a CSS URL through using the ‘theme’ parameter — see https://timeline.knightlab.com/docs/overriding-styles.html for more about that. Alternatively, use the plugin/shortcode so that your timeline is instantiated directly in the page on your site; in that case, CSS should affect it — there’s more about that in the link above; it is, admittedly, not extremely user-friendly, but it should be doable.

(coincidentally, I am listening to Pink Floyd’s “Animals” right now, which has a Hipgnosis album cover)

The code responsible for this has not changed in about five years; it’s simply that no one has noticed that the call to load an auxiliary font file tries to load one even if one isn’t specified.

If you are happy with the way your timeline looks, then there’s no issue. Another solution would be to add font="default" to the shortcode for the timeline.

We can change the code so that if the value for the font configuration is blank, it doesn’t attempt to load font..css which, for most installs, doesn’t exist… but in the grand scheme of things, besides cluttering the console, this is not a serious issue.

Wonderful! Happy to hear it.

If I understand your question correctly, you should still be able to use a stylesheet on your page to affect the presentation of the timeline, but moving from the original TimelineJS to TimelineJS3, CSS selectors are not guaranteed to be the same. In fact, they probably aren’t, so you would probably have to recreate the stylesheet.

I will acknowledge that, since the release of TimelineJS3, we have come to regret using such specific CSS selectors in the root CSS. More specific CSS selectors take priority over less specific ones, so if you load a supplemental stylesheet after the default timeline.css is loaded, you must use the same very-specific selectors to ensure that your rules are honored.

An alternative in a self-hosted model would be to only use one CSS file, either copying and modifying the base CSS file or working from the LESS files in the git repository. But if you’re using the Timeline plugin for WordPress, those changes would be at risk of being overwritten when the plugin is updated.

I’m not sure what you mean by “put them on your preview page,” but, basically, there’s no straightforward way to include your own styles when previewing; you’d need to make sure that the essential content of the timeline is what you want, and then override the styles by either replacing the CSS or adding a supplemental CSS file which selectively overrides styles set in the base CSS.

I hope that is reasonably clear.

Apologies. I should state that, by far, our preferred method for accepting support questions is via our Help Center, which we are much better able to monitor than the WordPress support forums.

When I load the “Work in progress” page linked above and open the Web Console, I see a series of messages showing that requests for the images were refused with a 403-Forbidden error. Despite this, when I copy the URLs for the images and load them directly, I do receive them.

Ultimately, this is an issue with your server’s configuration, and not something for which we can provide further problem-solving support.

Once again, sorry for the delayed response.

right now I get 404 errors for both links.

Certainly, if things work with an older version of the plugin, we’d like to understand why, and, if there’s something we need to do, to fix it.

I realize now that you’re using JSON. If you’re using JSON from the original version of timeline, you will need to add version="timeline2" to your shortcode as that is no longer the default. This is mentioned in the blog post but I’d understand if you didn’t read that!

Remember that we were expecting that Google Sheets would not be working for anyone this week, and people using Google Sheets and, by default, timeline2, would have nothing at all working. The old version of Google Sheets works with the new Timeline code, but the old version of JSON does not work with the new Timeline code.

Our assumption was that the number of WordPress users using the previous version JSON, is the smallest set of the user community, but that doesn’t mean they (you, maybe?) aren’t out there…

for https://www.ferentino.org/storia/in-breve/ the TimelineJS code is not being loaded.

on the EU site, there’s a line (line number 983):
<script type=’text/javascript’ src=’https://www.ferentino.eu/wp-includes/js/wp-embed.min.js?ver=5.5.1&#8242; id=’wp-embed-js’></script>

Your .org site ends hundreds of lines before that.

The plugin is working as expected on my test WordPress site as well, so I’m not sure I can help troubleshoot that issue.

Regarding the error on the EU site: there is a comment at the top of the JSON file, but the JSON file format does not support commenting:
https://www.ferentino.eu/mappa_odierna/storia_inbreve_ferentino.json

The .org version does not have the comment: https://www.ferentino.org/mappa_odierna/storia_inbreve_ferentino.json

please remove the comment and let us know if that solves the EU issue.

I am not seeing what you describe. When I visit https://www.ferentino.org/storia/in-breve/ the timeline appears to load as expected.

These changes are deployed. If you update to the latest version of the plugin (3.8.4.0), you may experience disruptions, as noted in the blog post.

However, we see today that Google has delayed their changes, so that now the Sheets API v3 will be shut down on January 26, 2021.

What that means to users of this plugin: you have less urgency to update the plugin. If you do update and experience issues, you could, in principle, roll back to versions of the plugin before 3.8.4.0. However, we’d also like to work with you to solve the issues for you and other users who might experience the problem. We ask that you post issues to our support system rather than here, as we are much more responsive there.

However, we recommend that you do it well in advance of January 2021, as who knows if Google will extend the deadline again.