Jekyll build fails because of colon in permalink

[scrawlon]

I'm having a small issue where Posts sent to Github won't build because there's a colon in the permalink value. I can fix this in my Github repo by manually replacing ":" with "%3A" in the permalink for each post, as described in Jekyll issue #5284

I realize this is really a Jekyll bug, but the permalink colons could be replaced in this plugin as a workaround.

Has anyone else run into this problem? I haven't found any other related issues here.

[mAAdhaTTah]

I haven't seen this problem posted here before, but you could probably resolve this by modifying the filename with the wpghs_filename hook. I'm surprised WordPress let's you have a slug with a colon, since we're just pulling from WP's slugs, but you should be able to work around it, or just drop the colon from the post slug, which you can edit the WP editor.

This is not the same as the title having a colon, which should be fine.

I don't think we're going to support this in the plugin itself, as its kind of a corner case and you can handle this in userland, so I'm going to close this issue, but feel free to comment if you need help.

[k0nsl]

I am having some issues too. Can somebody tell me if the below is correct or if that'll throw a build error?

---
ID: 130
post_title: The Nvidia GTX 690
author: k0nsl
post_date: 2012-05-02 11:18:54
post_excerpt: ""
layout: post
permalink: >
  https://k0nsl.org/blog/the-nvidia-gtx-690/
published: true
---

I noticed that there's a lot of unneeded junk before the content. For example, here is how one file looks like:

---
ID: 5695
post_title: IRC is online again
author: k0nsl
post_date: 2013-10-07 07:39:25
post_excerpt: ""
layout: post
permalink: https://k0nsl.org/blog/irc-online/
published: true
metric-2-votes:
  - "2"
metric-2-score:
  - "4.33333333333"
ag_review_post:
  - 'No'
ag_review_place:
  - Top of Post
ag_slide_crop:
  - 'yes'
ag_auto_play:
  - 'yes'
ag_share_style:
  - none
ag_author_style:
  - avatar_box
tmac_last_id:
  - "398144674692481024"
---

I'm unsure whether this will render a build error or not?

EDIT: This is the full error message:

 Generating: JekyllTitlesFromHeadings::Generator finished in 0.011972654 seconds.
 Fatal: Jekyll::Errors::InvalidURLError
 The URL /https:/k0nsl.org/blog/the-nvidia-gtx-690/ is invalid because it contains a colon.

Not sure why it saves the URL like this?

Any tips is welcomed :)

[mAAdhaTTah]

The URL /https:/k0nsl.org/blog/the-nvidia-gtx-690/ is invalid because it contains a colon.

I don't know where it's getting this url, but notice the protocol: http:/k0.... It's supposed to be https://, so it's missing a forward slash and interpreting that as part of the URL. Not sure what Jekyll is doing to get that, but I think that's unrelated to WPGHS.

[scrawlon]

The colon is not in the slug. The permalink contains "http://" that needs to be changed to "http%3A//". Any colon in the permalink causes Jekyll to error on build.

I'm surprised others haven't run into this issue. Either way, I have a work around. Thanks.

[mAAdhaTTah]

Wait, Jekyll uses the "permalink" field to generate its links?

[scrawlon]

Yes. A post "permalink" sets a post's url in Jekyll. It appears that Jekyll expects a relative url here.

Since my first post, I've realized that removing the colon allows Jekyll to build, but the links don't work. The permalink value is appended to the Jekyll base url.

If the permalink is set to "http%3A//wordpresspage.com/2017/08/01/post-name/". The resulting post url is, "http://jekyllpage.com/http%3A//wordpresspage.com/2017/08/01/post-name/"

If the permalink is set to "/2017/08/01/post-name/" then it works "http://jekyllpage.com/2017/08/01/post-name/"

[mAAdhaTTah]

Ah ok, hmmmm. Maybe the permalink shouldn't include the domain and such on export? Although that would be a BC break from what's currently up, I don't know if this is something that will have a material impact on non-Jekyll users.

This is certainly "fixable" through filters though; you can modify the post meta imported & exported, which as I mentioned in #183, and it's something that gets asked about a lot, so I should really write explicit documentation on how to do that.

I think I probably won't change the default value, but I'll leave this open to allow people to weigh in. #183 tracks my documentation writing job.