The flag should be implemented for compatibility with Jekyll, but should do nothing. For now at least, emphasize making whole builds fast enough that it's not needed.

See the group and filter_by_exp filters as models.

Site build only reports the first error. Collect them all.

(As referenced here:) tags/highlight.go won't compile in go < 1.16, because it uses "io/fs":

build github.com/osteele/gojekyll: cannot load io/fs: malformed module path "io/fs": missing dot in first path element

Previous versions used this code to test for the absence of the pygmentize command, but it does not work in go 1.16 because the error is not on the specified type:

	if e.Err == exec.ErrNotFound {

831ea53 changed to use this code, but this code does not compile in go < 1.16:

	if pathErr, ok := err.(*fs.PathError); ok {

Some plugins (e.g. jekyll-mentions) need to operate on text inside of HTML.

Add an HTML parsing staging after Liquid and Markdown conversion, and a plugin hook for this.

Does parsing the HTML affect performance? If so, only do if one of the plugins has used this hook.

This is implemented for serve. Factor out the watching library for use in build.

YAML MapSlice would be useful for this. Need to teach Liquid about this first.

Add an option to run the benchmarks on a CI server, for repeatability.

The server builds all the collections, but only generates non-collection pages on demand. It should build everything, so that it can report all the errors.

Documented here

to me a good benefit of this project is the small size, at least in comparison to Hugo. currently the go.sum is 113 lines:

https://github.com/osteele/gojekyll/blob/main/go.sum

compared to Hugo, which is a ridiculous 859 lines:

https://github.com/gohugoio/hugo/blob/master/go.sum

Use a logger instead of smattered fmt.Printfs?

I wonder if there has been any thought or discussions regarding using Chroma or another Go based code highligher?

Thanks

gist is implemented, but it ignores noscript.

At the least, it should warn when gist: noscript: true is present in the configuration.

Checklist

• I have search the issue list for my issue.
• I have verified the behavior with jekyll.
• I tried hard to create a reproducible test case.

System information

Liquid version: gojekyll --version
develop
Commit hash: (if version = develop)
9718b42

Expected behavior

Hyperlinks and all URLs work correctly.

Actual behavior and reproducer

Only the index page loads. All other pages (which are linked from the index page) give 404. I get the following error in gojekyll serve console output when I navigate to some other page (for example, clicking on the "articles" hyperlink on the home page).

# I run "gojekyll serve", server is running
Configuration file: /home/apb/code/abhijeetbodas2001.github.io/_config.yml
            Source: /home/apb/code/abhijeetbodas2001.github.io
    Server address: http://127.0.0.1:4000/
  Server running... press ctrl-c to stop.
# I now open my browser, and click on the "articles" hyperlink on the homepage (which goes to the localhost:4000/articles URL)
# I now get a 404 (I have a custom 404 page, which shows up in the browser.
# The following error pops up in console output:
[LiveReload] websocket: close 1001 (going away)
[LiveReload] websocket: close 1001 (going away)

I have my site source at https://github.com/abhijeetbodas2001/abhijeetbodas2001.github.io and am currently trying out gojekyll (have used only the ruby gem earlier).
I am running Debian 12 bookworm.

Would appreciate any sort of help on how to fix this. Thanks for all your efforts on this project!

System information

Fedora 38 x86_64

Liquid version: gojekyll --version
gojekyll version 2c83a35 (Build time: 2023-08-18T20:44)

Expected behavior

gojekyll to follow the symlink

Actual behavior

gojekyll overwrites the symlink with a directory

Steps to reproduce the behavior

1. cd example
2. rm -rf _site
3. mkdir ~/blog
4. ln -s ~/blog _site
5. gojekyll build

Implementation plan:

1. site build asks config whether the plugin is active. If so, it iterates over each page's front matter's redirect_from list

2. page load asks config whether the plugin is active. If it is and if the front matter contains a redirect_to, it changes this to a permalink and creates or appends the original page permalink to a redirect_from, so that downstream processing will do the right thing.

Implementation plan:

• Site.Read adds the files in $theme/assets, before adding the files in the main site (so that the latter takes precedence)
• layouts looks in $themes/_include, after looking in the main _include
• include_relative from the theme directory needs to look first in the corresponding non-theme location
• The sass copier should first copy files from $themes/_sass, then overwrite them with $site/_sass

Idea: Page rendering asks the config whether this is present. Or page rendering always calls applyLayout, which asks config.

Implementation plan:

Site.Read asks the config whether this plugin is present. If it is, it changes the permalink of any document with README.htmlto / before putting it in the routing table.

Checklist

• I have search the issue list for my issue.
• I have verified the behavior with jekyll.
• I tried hard to create a reproducible test case.

System information

Liquid version: gojekyll --version

Commit hash: v0.2.8 (built from source)

Expected behavior

Jekyll serves any page without the .html extension correctly, both during development and on GitHub Pages.

Actual behavior

GoJekyll returns a 404 for /page, but 200 for /page.html

Steps to reproduce the behavior

Provide the first of these that is practical:

Trivial enough that I did not create a minimal test case, but let me know if you cannot proceed without one.

Possible Solution

Support extensionless serving; let me know if this is something you’d like to support, and I can take a stab at implementing it & send you a PR.

This may need a different markdown library.

The react server does this, and it's fantastic. It means you only have one place to watch.

See the jekyll-feed plugin emulator as an example.

Do people use this?

I think this needs to be a callout to the npm package.

Implement the linenos argument to gist: {% highlight ruby linenos %}

Jekyll uses https://github.com/jekyll/classifier-reborn

For Go, look at https://github.com/avelino/awesome-go/#machine-learning, in particular https://github.com/jbrukh/bayesian.

GitHub search also turned up https://github.com/AlasdairF/Classifier.

Checklist

• I have search the issue list for my issue.
• [x ] I have verified the behavior with jekyll. (N/A)
• I tried hard to create a reproducible test case.

System information

Rocky 8
(installing error)

Expected behavior

go install github.com/osteele/gojekyll@latest will install & put a binary

Actual behavior

doesn't install, fails with the following:

...
go: github.com/osteele/gojekyll imports
	github.com/osteele/gojekyll/commands imports
	gopkg.in/alecthomas/kingpin.v2: gopkg.in/alecthomas/[email protected]: parsing go.mod:
	module declares its path as: github.com/alecthomas/kingpin/v2
	        but was required as: gopkg.in/alecthomas/kingpin.v2

Steps to reproduce the behavior

Rocky 8,
Go 1.19.1
go install l github.com/osteele/gojekyll@latest

Possible Solution

Fix go.mod file

Expected behavior

Add a draft release to project releases https://github.com/osteele/gojekyll/releases.

Actual behavior

❯ goreleaser --rm-dist
   • running goreleaser dev   
   • loading config file       file=.goreleaser.yml
   • SETTING DEFAULTS 
   • GETTING AND VALIDATING GIT STATE
   • LOADING ENVIRONMENT VARIABLES
   • CHECKING ./DIST  
   • rm-dist is set, removing ./dist
   • BUILDING BINARIES
   • skipped ignored build     target=darwin/386
   • new folder                folder=gojekyll_0.0.1_macOS_64bit key=darwinamd64
   • building                  binary=dist/gojekyll_0.0.1_macOS_64bit/gojekyll
   • new folder                folder=gojekyll_0.0.1_Linux_64bit key=linuxamd64
   • building                  binary=dist/gojekyll_0.0.1_Linux_64bit/gojekyll
   • new folder                folder=gojekyll_0.0.1_Linux_32bit key=linux386
   • building                  binary=dist/gojekyll_0.0.1_Linux_32bit/gojekyll
   ⨯ release failed            error=build failed for linux/386:
go build github.com/jeffjen/datefmt: no buildable Go source files in /Users/osteele/go/src/github.com/jeffjen/datefmt
# github.com/wellington/go-libsass/libs
../../wellington/go-libsass/libs/sass_number.go:8: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:151: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:153: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:157: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:159: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:164: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:166: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:170: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:175: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:186: undefined: SassNumber
../../wellington/go-libsass/libs/sass_number.go:166: too many errors

Steps to reproduce the behavior

❯ go get github.com/goreleaser/goreleaser
❯ git tag -af v0.0.1 -m "First release" && git push origin +v0.0.1
❯ goreleaser --rm-dist

More info

There appear to be two distinct problems: the "no buildable Go source files" warning re github.com/jeffjen/datefmt; and the "undefined: SassNumber" errors re github.com/wellington/go-libsass.

Before I added main: ./cmd/gojekyll to .goreleaser.yml, the commands above did create a release. The gojekyll in the release zip wasn't executable, though, since the config didn't refer to a main package. The build probably was skipping all the compilation, which is why it didn't run into the errors above. This does demonstrate that the upload part is (was) working.

See https://ci.appveyor.com/project/osteele/gojekyll https://github.com/osteele/gojekyll/runs/5171787377?check_suite_focus=true.

This issue is reported upstream at osteele/liquid#22.

Once the Liquid issue is fixed, wellington/go-libsass#20 may be an issue.

I want to use context data in filter

This can use site.RelativeFilenameToURL.

Some plugins use utils.ApplyToHTMLText. Something analogous could be added for tags.

Checklist

• I have searched the issue list for my issue.
• I have verified the behavior with jekyll.
• I tried hard to create a reproducible test case.

System information

Liquid version: 9718b42

Steps to reproduce the behavior

Minimal test case:

<div markdown="1">

<br>
<br>

</div>

Actual behavior

1. When a single file cannot be parsed, gojekyll terminates. With the current behavior, you have to fix one file at a time, and cannot see any patterns that might have been otherwise obvious.
2. gojekyll terminates with filename.md: markdown: EOF. This is not enough information to debug what’s wrong in that file.
3. The file contains markdown="1". Although the README says markdown="span" and markdown="block" are not supported, it does not explicitly say that markdown="1" is not supported.

Expected behavior

1. Keep going even if one file has an error, and report all errors to the user.
2. A better error message than filename.md: markdown: EOF would really help in debugging, especially if a feature is known not to be supported.
3. If the lack of support for markdown="1" is a known issue, then this should be added to the README in addition to markdown="span" and "block".

Possible Solutions

Listed above.

Thanks for a great tool, hoping I can use it as a drop-in replacement soon!

Implementation plan:

• Add a struct collectionList {collections []string} type.
• Reading config.yml unmarshals into this. If it's not empty, it creates a map and assigns the configuration from it.

The configuration struct currently specifies a map. Does this cause an error if the YAML is a list?

If so:

• mark Config.collections with yaml:"-"
• define collectionMap struct
• unmarshal into collectionMap
• assign Config.collections from collectionMap.collections

The jekyll-github-metadata plugin should have an option to cache GitHub requests. This would make it easier to run benchmarks that (1) don't include network latency (which is large over slow network connections, and highly variable in general).

This should happen as the project becomes more stable. I don't know if it's worth it yet.

Should --destination be relative to the site source or the current directory?