Search Doesn't (Always?) Appear on GitHub Pages

[jcolag]

I deployed my archive to GitHub Pages and it looks good except for the search box not appearing. Digging into the console, the browser tells me...

Loading failed for the <script> with source “https://jcolag.github.io/twitter/_pagefind/pagefind-ui.js”. twitter:36:1

The URL does, in fact, show a "Tweet not found" page, but I can see _pagefind/pagefind-ui.js and its associated files in the repository. The page itself uses a relative URL (/twitter/_pagefind/pagefind-ui.js), but you presumably already know that.

Is this a small bug for the edge case of using a big company's hosting to avoid a big company's hosting? Does this result from my fouling up something in the configuration? Or is it just a limitation of GitHub Pages that it doesn't correctly deploy thousands of files or deploying files in folders prefaced by underscore characters?

Thanks!

[bglw]

This'll be a result of GitHub Pages not serving urls that start with _. You'll want to update Pagefind to run with a bundle-dir option of pagefind (instead of _pagefind). Docs

tweetback/eleventy.config.js

Line 34 in 1fe10e9

execSync(`npx pagefind --source _site --glob \"[0-9]*/**/*.html\"`, { encoding: 'utf-8' });

Then update the css/js on the page to /pagefind/ instead of /_pagefind/

tweetback/index.11ty.js

Lines 271 to 272 in 1fe10e9

	<link href="/_pagefind/pagefind-ui.css" rel="stylesheet">
	<script src="/_pagefind/pagefind-ui.js" onload="new PagefindUI({ element: '#search', showImages: false });"></script>

[bglw]

(NB: This is probably a change worth contributing to tweetback generally, since GitHub Pages is a common deployment target. Pagefind 1.0 will also change this default since it gets hit a lot)

[jcolag]

That makes sense; I forgot that Pages is built around Jekyll. I'll experiment with this tomorrow and report back. Thanks!

[jcolag]

Good news! The search box now pops up and searches. Again, thanks.

Bad news? I'll try to run down where it might come from, but it looks like the pagefind code doesn't respect the specified pathprefix option. I can personally work around this by editing the URLs, but that probably doesn't help any visitors who might show up. I hoped that searching for pagefind-ui__result-link might turn up the code generating the links, but the only appearance looks like a random utility function.

[bglw]

Ah yes, I see why that happens. Two options here:

1. In your templating you could tag each page with a url metadata for Pagefind as shown here: Overriding the URL of a result
2. You could add a processResult hook to the Pagefind UI as shown here: Process result

The latter would look something like

new PagefindUI({
    ...
    processResult: function (result) {
        result.url = `/pathprefix${result.url}`;
        return result;
    }
    ...
});
``

[jcolag]

Excellent. I needed to wrap the prefix-ing in an if (result.url.indexOf('/pathprefix') < 0), since that apparently persists and changes during and after the search, but it's now functional. I also needed to hack the function into a string, so that it'd build without wrecking the existing interpolated string, but that's a minor detail. 👍

Might there be a way to read the path prefix in index.11ty.js? If so, I can do some more testing and polish, and submit it as a pull request. Otherwise, I think that this issue can be closed.

[nhoizey]

@jcolag a PR would be really welcome if you find how to make it.

I don't remember if it was planned to have pathPrefix in the eleventy variable, or somewhere else accessible inside templates.

[CarwilB]

The suggestion above from @bglw works, but I wasn't sure at first how to implement it.

This'll be a result of GitHub Pages not serving urls that start with _. You'll want to update Pagefind to run with a bundle-dir option of pagefind (instead of _pagefind). Docs

tweetback/eleventy.config.js

Line 34 in 1fe10e9

execSync(`npx pagefind --source _site --glob \"[0-9]*/**/*.html\"`, { encoding: 'utf-8' });

To clarify for more inexperienced folks like myself, this looks like replacing line 34 of tweetback/eleventy.config.js with:

execSync(`npx pagefind --bundle-dir pagefind --source _site --glob \"[0-9]*/**/*.html\"`, { encoding: 'utf-8' });

[anitagraser]

With the help of @CarwilB's comment, I managed to fix search on my page like this: anitagraser@472b265

[dalelane]

An alternative is to create an empty file called .nojekyll in the root of your GitHub Pages repo. That bypasses the Jekyll build, and I found that it got Search working for me as-is without needing to make any other changes.

cf. https://github.blog/2009-12-29-bypassing-jekyll-on-github-pages/

[jimken-mido]

Thank you! The .nojekyll trick worked a charm for me.