algolia / jekyll-algolia Goto Github PK

View Code? Open in Web Editor NEW

213.0 64.0 35.0 33.31 MB

Add fast and relevant search to your Jekyll site

Home Page: https://community.algolia.com/jekyll-algolia/

License: MIT License

Ruby 64.76% Shell 0.50% HTML 0.71% JavaScript 8.61% CSS 7.07% Pug 3.90% SCSS 14.41% Sass 0.04%

jekyll-algolia's Introduction

DEPRECATED

This plugin is deprecated and no longer maintained by Algolia.

As of November 2022, it still works on Jekyll 3. Issues are still open, as a place to discuss, but Pull Requests will be closed.

If you're interested in becoming a maintainer and giving it a second life, feel free to fork it (or get in touch with @Algolia to become an official maintainer).

Below is the old README, for archiving purposes:

Jekyll Algolia Plugin

Add fast and relevant search to your Jekyll site.

Usage

$ bundle exec jekyll algolia

This will push the content of your Jekyll website to your Algolia index.

Documentation

Full documentation can be found on https://community.algolia.com/jekyll-algolia/

Installation

The plugin requires at least Jekyll 3.6.0 and Ruby 2.3.0.

First, add the jekyll-algolia gem to your Gemfile, in the :jekyll_plugins section.

# Gemfile

group :jekyll_plugins do
  gem 'jekyll-algolia', '~> 1.0'
end

Once this is done, download all dependencies with bundle install.

Basic configuration

You need to provide certain Algolia credentials for this plugin to index your site.

If you don't yet have an Algolia account, we suggest that you open a free Community plan here. You can find more information about the Algolia plans in our FAQ.

Once signed in, you should get your application ID from your dashboard and define it inside your _config.yml file like this:

# _config.yml

algolia:
  application_id: 'your_application_id'

Run it

Once your application ID is setup, you can run the indexing by running the following command:

ALGOLIA_API_KEY='your_admin_api_key' bundle exec jekyll algolia

Note that ALGOLIA_API_KEY should be set to your admin API key.

More about the Community plan

The Algolia Community plan lets you host up to 10k records and perform up to 100k add/edit/delete operations per month (search operations are free). The plan is entirely free, with no time limit.

What we ask in exchange is that you display a "Search by Algolia" logo next to your search results. Our InstantSearch libraries have a boolean option to toggle that on an off. If you want more flexibility, you can find all versions of our logo here.

If you need more information about the other Algolia plans, you can check our FAQ.

Thanks

Thanks to Anatoliy Yastreb for a great tutorial on creating Jekyll plugins.

jekyll-algolia's People

Contributors

Stargazers

Watchers

jekyll-algolia's Issues

Cannot run jekyll algolia since the update

I've used algoliasearch before and learnt that now it is replaced by jekyll-algolia. Fine.

But I've followed the documentation and tried to do exactly as you said, but I get a:

Dependency Error: Yikes! It looks like you don't have algoliasearch-jekyll or one of its dependencies installed. In order to use Jekyll as currently configured, you'll need to install this gem. The full error message from Ruby is: 'cannot load such file -- algoliasearch-jekyll' If you run into trouble, you can find helpful resources at https://jekyllrb.com/help/!

Log message when the plugin is pushing records to Algolia [Feature Request]

Currently, the plugin doesn't log a standby message before pushing records to Algolia.
I expect to see something (non-verbose log msg) like the following..

Pushing records to Algolia...
✔ Indexing complete

similarly, when it errors:

Pushing records to Algolia...
[✗ Error] Invalid credentials

The jekyll-algolia plugin could not connect to your application ID using the
API key your provided.

Make sure your API key has access to your {application_id} application.

You can find your API key in your Algolia dashboard here:
   https://www.algolia.com/licensing

Attributes to snippet setting not correctly pushed

I want to report a bug:

What is the current behavior?

Every time I push to algolia, it just duplicates all the records.
Also, not all the settings are copied , or updated to the index
For example:

algolia:
  settings:
    attributesToSnippet: ['content:10']

rendered:

Originally posted here #39

Combine `diff` and `atomic` mode

From the readme:

By default, the plugin will try to be smart when pushing content to your index: it will only push new records and delete old ones insted of overwriting everything.
...
The drawback is that [atomic mode] will consume much more operations as you will have to push all your records to a new index each time.

Why couldn’t atomic mode only push changed, new, and deleted records to the *_tmp index (like diff mode), then swap the two indices? Example:

# my-index
- a
- b
- c
# my-index_tmp
- a
- b
- c

# => add `d`
#   - add `d` to `my-index_tmp`
#   - swap the two indices
# my-index
- a
- b
- c
- d
# my-index_tmp
- a
- b
- c

# => add `e`
#   - add `d` and `e` to `my-index_tmp`
#   - swap the two indices
# my-index
- a
- b
- c
- d
- e
# my-index_tmp
- a
- b
- c
- d

Migration guide from algoliasearch-jekyll

The documentation should contain a guide indicating how to migrate from algoliasearch-jekyll

The main changes are the renaming of the options and the default indexing mode being set to diff instead of atomic. Everything else, including example should be available in the documentation.

Algolia command not found

I want to report a bug:

What is the current behavior?

fatal: 'jekyll algolia' could not be found. You may need to install the jekyll-algolia gem or a related gem to be able to use this subcommand.

Commands executed:

root@699778ab0907:/app# gem install jekyll-algolia
Successfully installed jekyll-algolia-1.1.5
1 gem installed

root@699778ab0907:/app# bundle exec jekyll algolia
fatal: 'jekyll algolia' could not be found. You may need to install the jekyll-algolia gem or a related gem to be able to use this subcommand.

FYI: I'm under Docker containers here is my Dockerfile:

FROM ruby:latest
MAINTAINER Peter Etelej <[email protected]>

RUN apt-get -qq update && \
	apt-get -qq install nodejs -y && \
	apt-get install -y locales && \
	gem install -q bundler

RUN mkdir -p /etc/jekyll && \
	echo 'source "https://rubygems.org"' >> /etc/jekyll/Gemfile && \
	echo 'gem "github-pages"' >> /etc/jekyll/Gemfile && \
	echo 'gem "execjs"' >> /etc/jekyll/Gemfile && \
	echo 'gem "rouge"' >> /etc/jekyll/Gemfile && \
	echo 'gem "hash-joiner"' >> /etc/jekyll/Gemfile && \
	echo 'gem "jekyll-github-metadata"' >> /etc/jekyll/Gemfile && \
	echo 'gem "jekyll-last-modified-at"' >> /etc/jekyll/Gemfile && \
	printf "\nBuilding required Ruby gems.\n\n" && \
	bundle install --gemfile /etc/jekyll/Gemfile --clean

RUN apt-get clean && \
	rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

ENV BUNDLE_GEMFILE /etc/jekyll/Gemfile

EXPOSE 4000

ENTRYPOINT ["bundle", "exec"]

CMD ["jekyll", "build", "--watch"]

Ruby version used:

ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]

Jekyll version used:

jekyll 3.6.2

Add instructions on how to build an autocomplete of results

The records should be compatible with DocSearch, to it should be possible to use the DocSearch.js library to query the index. A demo would have to be built to verifiy this.

capturing excerpts for pages

I want to report a bug:

What is the current behavior?
the excerpt in the algolia record does not capture excerpts for pages, it only seems to grab them for posts or documents

What is your expected behavior?
I would expect a record for a page to also have excerpt_text available
Steps to reproduce the issue:

Add instructions on how to use the plugin on Netlify

The documentation should indicate how to use the plugin on Netlify. This should be the default integration.

As Netlify accepts custom plugin, it should be straightforward.

BUG: Files excluded from Algolia seems to be deleted from `_site` folder

I want to report a bug:

Files excluded from Algolia seems to be deleted from _site folder.

What is the current behavior?

When running command bundle exec jekyll algolia index.htmlis deletes from _site_ folder. If I add more files to exclude in with the files_to_exclude config, more files are deleted. Bug seems to have appeared with the jekyll-algolia (1.1.4) version.

Update: I see that also the 404.html gets deleted.

What is your expected behavior?

Please don't delete files in the _site folder.

Commands to reproduce:

$ jekyll build
$ ls _site/
2015  2016  2017  2018  404.html  about  assets  electronics  feed.xml  homelab  index.html  robots.txt  search  sitemap.xml  work-area
$ ALGOLIA_API_KEY='my-key' bundle exec jekyll algolia
$ ls _site/
2015  2016  2017  2018  about  assets  electronics  feed.xml  homelab  robots.txt  search  sitemap.xml  work-area

Ruby version used:

ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

Jekyll version used:

jekyll 3.7.3

before_indexing_each hook returns an error

I want to report a bug: `before_indexing_each` hook returns an error

What is the current behavior?

I've added the hook to exclude nodes with certain attributes like this:

module Jekyll
  module Algolia
    module Hooks
      def self.before_indexing_each(record, node, context)
        # Do not index related-article
        return nil if node.attr('class') =~ 'related-article'
        # Do not index math blocks
        return nil if node.attr('class') =~ 'math'
        record
      end
    end
  end
end

But it returns an error:

jekyll 3.7.3 | Error:  type mismatch: String given

How can I fix it?

Ruby version used:

2.4.2

Jekyll version used:

3.7.3

relative_path_from: different prefix: (ArgumentError)

I want to report a bug:

What is the current behavior?

Installed jekyll-algolia, added algolia configs to _config.yml and run bundle exec jekyll algolia --dry-run --trace --verbose

What is your expected behavior?

Successfully complete a dry-run.

Git repository to reproduce the issue:

I have a fairly complex Jekyll repo I'm testing this with (using Gulp, etc.). Not entirely sure if the problem is because I have source and destination set in _config.yml or if maybe it's related to a plugin (perhaps jekyll-paginate-v2 since it seems to error out when ignoring files for the index)

Here's the full stacktrace:

Extracting records...
Skipping _pages/404.md
Extracting records from _pages/about.md
Skipping articles.xml
Skipping atom.xml
Extracting records from _pages/contact.md
Extracting records from _pages/faqs.md
Skipping feed.json
Extracting records from _pages/home.md
Skipping humans.txt
Skipping mastering-paper.xml
Skipping paperfaces.xml
Extracting records from _pages/portraits.md
Skipping procreate-paintings.xml
Skipping robots.txt
Extracting records from _pages/sitemap.md
Extracting records from _pages/style-guide.md
Extracting records from _pages/support.md
Extracting records from _pages/tag.md
Extracting records from _pages/terms.md
Skipping til.xml
Extracting records from _pages/work.md
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping .html
Skipping sitemap.xml
E:/Ruby24-x64/lib/ruby/2.4.0/pathname.rb:520:in `relative_path_from': different prefix: "E:/" and ".tmp/src" (ArgumentError)
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.2/lib/jekyll/algolia/file_browser.rb:52:in `relative_path'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.2/lib/jekyll-algolia.rb:94:in `block in write'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:329:in `block (2 levels) in each_site_file'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:328:in `each'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:328:in `block in each_site_file'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:327:in `each'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:327:in `each_site_file'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.2/lib/jekyll-algolia.rb:93:in `write'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:75:in `process'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.2/lib/jekyll-algolia.rb:57:in `run'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.2/lib/jekyll/commands/algolia.rb:42:in `block (2 levels) in init_with_program'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/exe/jekyll:15:in `<top (required)>'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/bin/jekyll:23:in `load'
        from E:/Ruby24-x64/lib/ruby/gems/2.4.0/bin/jekyll:23:in `<main>'

Ruby version used:

ruby 2.4.2p198 (2017-09-14 revision 59899) [x64-mingw32]

Jekyll version used:

jekyll 3.7.2

Unicode Symbols

I want to suggest a feature:

Search strings that contain Unicode symbols.

What is your use case for such a feature?

Many things that I write contains symbols that are not included in a default charset,
they are Unicode symbols like ∀, λ, →, and among others. I use these symbols
because my writing is about math and other stuff related. So, I would like
to have the chance to search by using those symbol that appears in the post
as in a normal paragraph or into a block code that it's pretty common.

What is your proposed API? Is this a new option? A new behavior?

The new option could be specified in the _config.yml file:

algolia:
  ...
  index_name:     'notes'
  index_unicode_symbols: true

Markdown paragraphs parsed as '\n\n' leading to "Record is too big" error

First, thank you for developing this plugin!

I'm having trouble getting the plugin to successfully index my site. bundle exec jekyll algolia always fails with:

[✗ Error] Record is too big.

Looking at the resulting json log file, I notice that for certain markdown pages, it is failing to recognize paragraphs. Instead, it parses them as a double-newline \n\n. For large pages, this results in one giant <p> node which exceeds the 10KB limit.

Example page and log file: https://github.com/evmo/jekyll-algolia-error

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]

jekyll 3.7.3

Add instructions on how to integrate the plugin on GitHub pages

The documentation should have clear instructions on how to use the plugin to index content on GitHub pages.

It should explain both:

How to run the command locally to update the records
Make it automated so it's updated on each gh-pages deploy. This will require some TravisCI integration.

Giving an example of a search into a specific collection

An issue was raised on the previous plugin to be able to specify different indices to index different kind of content: algolia/algoliasearch-jekyll#37

I don't think it would be necessary to push to different indices (and it will increase the code complexity), but the same end-goal can be achieved using faceting on the same index, even with records of very different types.

I should write a guide explaining how one can do two different kind of searches with only one index. I could have a generic search into the website content (pages and posts), and another into one specific collection (list of movies?). Everything can still be pushed to the same index, but by either using faceting on the type from the front-end or using secure API key, one would be able to target one or the other.

Records duplicate with every push

I want to report a bug:

What is the current behavior?

Every time I push to algolia, it just duplicates all the records.
Also, not all the settings are copied , or updated to the index
For example:

algolia:
  settings:
    attributesToSnippet: ['content:10']

rendered:

What is your expected behavior?

I would expect it compares the records and only make the changes accordingly. Every time I get this:

Found 116 files                                                                  
Updating settings                                                                
Inspecting existing records in index diybiosphere...                             
Updating records in index diybiosphere...                                        
Records to delete: 0                                                             
Records to add:    247                                                           
✔ Indexing complete

I would expect all my settings to pass to the index. But even when I try to set up ['*'] in attributesToRetrieve or something. It doesn't render appropriately

Steps to reproduce the issue:
This is my repo: https://github.com/DIYbiosphere/sphere

Keys in front-matter can override keys needed by the plugins

I want to report a bug:

What is the current behavior?

When a user adds a weight entry to their front-matter, it overwrites the weight attribute of the record, added by the plugin. This attribute is used by the default ranking strategy and will mess up the relevance.

What is your expected behavior?

Arbitrary entries added to the front-matter by users should not impact the default behavior of the plugin.

Git repository to reproduce the issue:

This has been discussed on tomjoht/tomjoht.github.io#3. The current relevance is weak because of that.

What is your proposed API? Is this a new option? A new behavior?

I see two ways of solving this issue:

Putting all front-matter keys inside a `frontmatter` root key

That way, everything that is manually added by the user is neatly stored into a clearly identifiable namespace. This raises questions about keys like excerpt or layout that can be defined in the frontmatter, but can also have default values defined by Jekyll. Should they then be in the root, or in the frontmatter key?

This will also be a breaking change, as we're changing the format of the records...

Making the plugin have precedence over the front-matter

If a key is used by the plugin but is also defined in the front-matter, then the plugin key should have precedence. This will make some keys non-accessible to some users, as they will get overwritten by the plugin no matter what they do. This will make sure the search always works, but the cost is that users might have to rename some keys of their front-matter if they want to use them in their display.

Pages at /blog/pages/*/ are not excluded

If you go to dzello.com and search for test, you will see some pagination pages in the search results.

Source code for the repo is at dzello/dzello-dot-com.

Allow settings update from the dashboard

Follow up of #29.

The current behavior of configuring settings can be confusing. Users can edit settings directly from the Algolia dashboard, or configure them in the settings key of _config.yml. If changed from the dashboard, they will get overwritten on the next push.

I might be able to improve this behavior by only overwriting settings when something is defined in the settings option. If nothing is set, we keep the settings as-is, allowing people to tweak them through the Dashboard.

I will still need to push some default settings the first time even if no settings are set, but for that I can simply check if the index exists or not. If it does not, I create one with default settings. If it exists, I don't touch it

Weird versioning error happening on Travis

I want to report a bug:

I tried out a few things (see recent commits), but they all failed in travis while installing the dependencies (see the logs)

What is the current behavior?

Can't install on Travis

What is your expected behavior?

Can install on Travis

Git repository to reproduce the issue:

https://github.com/haroenv/blog

Ruby version used:

2.2 I think

Jekyll version used:

3.7.3

Clean the footnote links

Paragraphs indexed and listed in results sometimes contain footnote links that are rendered as plain text, which is not optimal:

Example here:
https://nicolas-hoizey.com/recherche.html?q=posse

Transforming 404 pages into search pages

This has been originally posted on algolia/algoliasearch-jekyll-hyde#4

When a URL tries to reach a post that does not resolve to a real page, such as http://community.algolia.com/algoliasearch-jekyll-hyde/whatever currently the visitor is shown the 404.html page.
But now that we have Search, how about having JavaScript take the "whatever" and put it in the search form, and automatically issue a search?

I don't think this is something that could be part of the plugin directly, but I'd be interested into adding this to themes.

Create a JSON file when plugin runs in dry-run mode [Feature Request]

Allow users to verify what data is actually pushed to Algolia

Expectation

$ bundle exec jekyll algolia --dry-run

==== THIS IS A DRY RUN ====
  - No records will be pushed to your index. You can verify data that
    would be pushed by inspecting the file below.
  - '[index-name]-[hash].json' has been saved to your source directory [source-path]

with its contents being a pretty_generate dump of JSON record data

Deprecate algoliasearch-jekyll

The previous plugin should be marked as deprecated.

It will involve:

Doing a new release of algoliasearch-jekyll
Including deprecation warnings, redirecting to the new plugin
Updating the description displayed on RubyGems to redirect to jekyll-algolia
Add mention in the readme as well
Write a migration guide to move to jekyll-algolia from algoliasearch-jekyll
Archive the previous repo so issues and PR are closed

Use Jekyll hook to trigger index

I want to suggest a feature:

What is your use case for such a feature?

If updating the index was triggered by a Jekyll hook as opposed to (or addition to) a separate command, then the index would update automatically every build.

You would want to control what environment the hook is run in. Checking if ALGOLIA_API_KEY exists seems like a good way to this.

What is your proposed API? Is this a new option? A new behavior?

None. You would install the plugin, run jekyll with the ALGOLIA_API_KEY environment variable and it would work.

Synonyms are cleared when doing an atomic push

Originally opened at algolia/algoliasearch-jekyll#62

When doing an atomic push, synonyms (and query rules) are not correctly kept. I'll need to first grab the synonyms from the index and then re-push them.

Migration guide from algoliasearch-jekyll to jekyll-algolia

The documentation should include a guide on how to migrate from the previous version to this one.

Main points of attention are:

The minimum versions of Jekyll and Ruby have been increased
Options do not have the same names
Command is jekyll algolia instead of jekyll algolia push
lazy_update mode is the default now

Add instructions on how to display the results with InstantSearch.js

A generic tutorial of using InstantSearch.js with to display results. We could use a common theme (Hyde is good candidate) explaining how to integrate the front-end. We should not maintain an official fork of Hyde, simply reuse its code as an example.

Unable to batch push data on the index

Hello,

Just found out about Algolia and its Jekyll plugin.

However, when I run the command:

ALGOLIA_API_KEY='secret' bundle exec jekyll algolia --trace

I stumble upon the following issue:

Extracting records...                                                            
Updating records in index blog.frankel.ch...                                     
Records to delete: 33                                                            
Records to add:    57                                                            
bundler: failed to load command: jekyll (/Users/i303869/.rbenv/versions/2.4.2/bin/jekyll)
NoMethodError: undefined method `[]' for nil:NilClass
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:198:in `record_too_big?'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:58:in `block in identify'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:57:in `each'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:57:in `identify'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:23:in `stop'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:154:in `rescue in block in update_records'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:151:in `block in update_records'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `each'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `each_slice'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `update_records'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:192:in `run'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll-algolia.rb:119:in `write'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/lib/jekyll/site.rb:75:in `process'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll-algolia.rb:57:in `run'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-algolia-1.1.0/lib/jekyll/commands/algolia.rb:42:in `block (2 levels) in init_with_program'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
  /Users/i303869/.rbenv/versions/2.4.2/lib/ruby/gems/2.4.0/gems/jekyll-3.7.2/exe/jekyll:15:in `<top (required)>'
  /Users/i303869/.rbenv/versions/2.4.2/bin/jekyll:23:in `load'
  /Users/i303869/.rbenv/versions/2.4.2/bin/jekyll:23:in `<top (required)>'

Interestingly enough, if I remove all the posts (but not the pages), or use the example repo, it works.

Do you have any way I could debug further? Any hint/help appreciated.

My repo is hosted on a private Gitlab repo, but should the need be, I could give you access rights.

<pre> indexing issue

This issue was mention in #45.
In my repository (https://github.com/jonaprieto/jonaprieto.github.io/)
I'm having this problem trying to index pre blocks.

I got this:

$ jekyll algolia
...
jekyll 3.7.2 | Error:  undefined method `[]' for nil:NilClass

Provide more hooks parameters

I want to suggest a feature:

The issue I'm currently facing is that I want to index multi-dimensionnal author data along with the content instead of a simple string. The data is available in one of the _data file.

Here's a snippet of the data file I want to use:

main:
    firstName: John
    lastName: Doe
    job: Developer
    company: Geek
    url: me
    image: assets/resources/me/me.jpg

I'd suggest a change in the before_indexing_each(record, node) method to also add the site parameter (which would also let access the configuration, etc.).

FloatDomainError: Infinity when trying to build an index

Hey there,

I'm trying to implement this search in my Jekyll installation. Jekyll is v3.7.3 and everything else should be up to date as well. When I'm trying to build the index file, I see FloatDomainError: Infinity:

Configuration file: /Users/r/dev/_config.yml
Processing site...
bundler: failed to load command: jekyll (/usr/local/bin/jekyll)
FloatDomainError: Infinity
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-paginate-1.1.0/lib/jekyll-paginate/pager.rb:14:in `ceil'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-paginate-1.1.0/lib/jekyll-paginate/pager.rb:14:in `calculate_pages'
  /Users/r/dev/_plugins/jekyll-tagsgenerator.rb:19:in `paginate'
  /Users/r/dev/_plugins/jekyll-tagsgenerator.rb:15:in `build_subpages'
  /Users/r/dev/_plugins/jekyll-tagsgenerator.rb:9:in `block in generate'
  /Users/r/dev/_plugins/jekyll-tagsgenerator.rb:8:in `each'
  /Users/r/dev/_plugins/jekyll-tagsgenerator.rb:8:in `generate'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.7.3/lib/jekyll/site.rb:174:in `block in generate'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.7.3/lib/jekyll/site.rb:172:in `each'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.7.3/lib/jekyll/site.rb:172:in `generate'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.3.4/lib/jekyll/algolia/overwrites/jekyll-algolia-site.rb:24:in `process'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.3.4/lib/jekyll-algolia.rb:73:in `run'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.3.4/lib/jekyll/commands/algolia.rb:31:in `block (2 levels) in init_with_program'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.7.3/exe/jekyll:15:in `<top (required)>'
  /usr/local/bin/jekyll:23:in `load'
  /usr/local/bin/jekyll:23:in `<top (required)>'

bundle exec jekyll algolia --verbose does that:

Configuration file: /Users/r/dev/_config.yml
         Requiring: /Users/r/dev/_plugins/jekyll-tagsgenerator.rb
         Requiring: /Users/r/dev/_plugins/jekyll-capitalize-all.rb
         Requiring: /Users/r/dev/_plugins/sitemap_generator.rb
         Requiring: /Users/r/dev/_plugins/jekyll-autgenerator.rb
         Requiring: jekyll-paginate
         Requiring: jekyll-feed
         Requiring: jekyll-typogrify
         Requiring: jekyll-email-protect
         Requiring: liquid_reading_time
         Requiring: nokogiri
         Requiring: json
         Requiring: mini_portile
Processing site...
       EntryFilter: excluded /Gemfile.lock.old
       EntryFilter: excluded /node_modules
       EntryFilter: excluded /README.md
       EntryFilter: excluded /Rakefile
       EntryFilter: excluded /package.json
       EntryFilter: excluded /gulpfile.js
       EntryFilter: excluded /Gemfile
       EntryFilter: excluded /Gemfile.lock
       EntryFilter: excluded /script.py
           Reading: _posts/2017-07-27-something.html
       EntryFilter: excluded /assets/css
jekyll 3.7.3 | Error:  Infinity

Running on a Mac with High Sierra, Ruby was installed with Brew. Could that be the issue here?

Thanks!

Move the ./errors folder inside of ./lib

./errors only contain templates for errors displayed by the plugin. It should live under ./lib.

All other folders at the root are meta-folders, not part of the gem, but part of the tooling system (tests, documentation, scripts, etc).

Split `jekyll algolia` into two commands

I feel that command jekyll algolia indexing records and pushing data to a cloud server is a source of security concerns.

The user has no idea what data has been collected and pushed
The user has no idea if the connection between their terminal and remote is secure / encrypted / open to Man-in-the-middle attacks.

One way I can think of is to split the functionality into two commands and output more messages to the user terminal

One command builds the current site, and indexes records (without checking the remote index). This command doesn't require an Internet connection and will result in writing the data to a file on disk in a special directory (say ./.algolia/ akin to how GIT writes a commit, only readily accessible by the user)
The other command first establishes a secure connection to remote Algolia, then reads remote index and then finally pushes the latest local index in .algolia/ directory to remote.
This command would not initiate a Jekyll Build process and purely search-index-centric.

By using a special directory to hold the index data, the user can inspect the search data (in JSON), will more likey add it to their .gitignore or similar files and therefore, the directory can also be a safe place to hold their _algolia_api_key file.

/cc @DirtyF

Adding default snippeting values

I want to suggest a feature:

The default index settings could define some sane values for snippeting (on content) directly on the index so this could more easily be used in the front-end.

What is your use case for such a feature?

Paragraphs can be long, and displaying a snippet of the matching element can make the display more compact.

What is your proposed API? Is this a new option? A new behavior?

I think adding attributesToSnipet: ['content:35'] should be ok.

Custom collection documents with only frontmatter (no content) are not indexed

I want to report a bug:

Custom collection documents that only have frontmatter (but no main content below the frontmatter) are not indexed

What is the current behavior?

When the plugin is run, documents in a custom collection that have no content (but do have frontmatter) are not processed. If any arbitrary content is added to a document in the custom collection, when the plugin is run again that document is successfully indexed.

What is your expected behavior?

If a collection is set to "output: true" then all files should be indexed, even if they do not have any content in their main body (but do have frontmatter)

Ruby version used:

ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-darwin16]

Jekyll version used:

jekyll 3.7.3

Showcase minimal-mistakes as one of the supported themes

https://github.com/mmistakes/minimal-mistakes

Use `facetingAfterDistinct=true` in the front-end codes

facetingAfterDistinct=true allow faceting count to be exact when using distinct. It does not work if all records sharing the distinct key have a different schema.

The plugin heavily relies on distinct and creates records with similar schemas so the feature can be used.

I'm keeping this issue open to remember to enable it in the front-end examples.

Plugin doesn't recognize link anymore

In the latest version of the plugin, I stumble upon the following error while launching the command jekyll algolia:

Progress: |=================================================================  Liquid Exception: Could not find document '_pages/01-books.html' in tag 'link'. Make sure the document exists and the path is correct. in /builds/nfrankel/nfrankel.gitlab.io/_posts/2018-01-14-unit-test-vs-integration-test.adoc
jekyll 3.7.3 | Error:  Could not find document '_pages/01-books.html' in tag 'link'.

Here's my Asciidoctor snippet:

While you're at it, have a look at my book link:{% link _pages/01-books.html %}[Integration Testing from the Trenches^], dedicated to, guess what, integration testing.

This happens with version 1.2.7 of the plugin. Rolling back to 1.1.4. removes the error.

You know my repo URL :-)

bug report, jekyll-algolia on safari of iOS 9.0 couldn't disappear normally.

I want to report a bug:

When I put the jekyll-algolia on my blog, I found it didn't appear normal on the Safari or Chrome of iOS 9.0 of the iphone 6s plus.
Other explore's appear is good.

The example web is : http://gaeblogx.com/search/, which github project is
SeraphRoy/SeraphRoy.github.io
or my site: http://yefeiyu.github.io/search/
(github site is yefeiyu/yefeiyu.github.io)
Now, I put the pictures on here, the same site on different mobile, one is 5s, the other is 6s plus.

picture 1 : on 5s

picture 2 : on 6s plus

picture 3: on 5s

picture 4: on 6s plus

Simplifying format of the record

I want to suggest a feature:

I'd like to suggest improvements on the current format of the records.

What is your use case for such a feature?

The initial format has been done so it can be compatible with docsearch.js. DocSearch is incredible for adding search to documentation websites, and I think it is even superior to this Jekyll plugin on this specific kind of data. I don't think there is a need to have the records schema compatible with DocSearch anymore, and I'd like to make it as straightforward as possible for users.

What is your proposed API? Is this a new option? A new behavior?

Here are the keys I'd like to remove/rename/modify:

hierarchy is a currently an object, with lvl0 through lvl6 keys. It represents the upward hierarchy of headers from the matching paragraph. I suggest compacting it into an array that only contains the actual headers. So, instead of {lvl0: null, lvl1: 'Video', lvl2: 'Editing', lvl3: null, lvl4: null, lvl5: null, lvl6: null}, we would only have ['Video', 'Editing']. Display will be easier, and relevance will stay the same.
weight is an object we use for the custom ranking. It contains a heading weight (the higher the value, the more important the heading is), as well as an index of the position of the paragraph in the page. I suggest renaming it to custom_ranking as this better explain what it used for, and also avoids naming collision with other values that can be set in the frontmatter.
tag_name almost always is set to p (or any selector defined by the user). This value can be infered from the html element if it is really needed, but today I don't see a point why we should use it so I suggest we remove the key.
draft should be removed as well. It is always false, unless --drafts is passed to the command. I don't see why anyone would need to make drafts searchable, so I think it's safer to remove it altogether.
layout is here because it's an almost mandatory front-matter key, but it does not make sense to have it as part of the records. I suggest we remove it.
ext contains the original file extension (.html or .md). This one also, not sure it is needed in the final record. I suggest we remove it as well.

All the other fields (content, text, excerpt_html, excerpt_text, categories, tags, title, date, type, anchor, slug, url) and any custom field set in the front-matter will be kept.

Unable to batch push data on the index

Hello,

Just found out about Algolia and its Jekyll plugin.

However, when I run the command:

ALGOLIA_API_KEY='secret' bundle exec jekyll algolia --trace

I stumble upon the following issue:

Processing site...                                                               
Extracting records...                                                            
Updating records in index prod_BLOG_SEARCH...                                    
Records to delete: 0                                                             
Records to add:    276                                                           
bundler: failed to load command: jekyll (/usr/local/bin/jekyll)
NoMethodError: undefined method `[]' for nil:NilClass
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:198:in `record_too_big?'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:58:in `block in identify'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:57:in `each'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:57:in `identify'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/error_handler.rb:23:in `stop'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:154:in `rescue in block in update_records'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:151:in `block in update_records'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `each'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `each_slice'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:150:in `update_records'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/algolia/indexer.rb:192:in `run'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll-algolia.rb:119:in `write'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.6.2/lib/jekyll/site.rb:75:in `process'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll-algolia.rb:57:in `run'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-algolia-1.1.0/lib/jekyll/commands/algolia.rb:42:in `block (2 levels) in init_with_program'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `block in execute'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `each'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/command.rb:220:in `execute'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary/program.rb:42:in `go'
  /usr/local/lib/ruby/gems/2.5.0/gems/mercenary-0.3.6/lib/mercenary.rb:19:in `program'
  /usr/local/lib/ruby/gems/2.5.0/gems/jekyll-3.6.2/exe/jekyll:15:in `<top (required)>'
  /usr/local/bin/jekyll:23:in `load'
  /usr/local/bin/jekyll:23:in `<top (required)>'

Make the plugin known

Post it to JAMStack-fr
Tell Netlify about it
Tell CloudCannon about it
Add it to the official list of plugins
Update it from the Awesome Jekyll list

AwesomePrint alters Logger color luminance

While Jekyll::Algolia::Logger modifies logged output when running the jekyll algolia command, require "awesome_print" brightens the colors for Jekyll Logger levels.

This is not documented (and probably not something I'd want when I decide to use this plugin)

Documenting average number of post to expect in a free plan

I want to report a bug:

It is hard for a new user to estimate if their blog/website will fit in the free Community plan.

What is the current behavior?

Algolia plans are based on the number of records. Blog will most likely reason in number of posts or pages. The plugin will split each page/post into several records, making the estimation hard.

What is your expected behavior?

There is no exact formula to know if a website will fit in a given plan, as it will depend on the length of the pages/posts as well as some config passed to the plugins.

Still, it should be possible to give a ballpark estimation. If we consider that each page contain 10 paragraphs, we can estimate how many posts it means, and even give an example like "one post ever week for X years".

It could also mention running jekyll algolia --dry-run to have an exact estimate of the number of records generated.

Setting a default `index_name`?

I want to suggest a feature:

What is your use case for such a feature?
I want to make the getting started guide as short as possible. I want people trying the plugin for the first time to be up and running quickly.

What is your proposed API? Is this a new option? A new behavior?
The current getting started asks user to define their application_id and index_name in the settings. The application ID is generated by Algolia, but the index name can be whatever they want.

Maybe we could provide a default index name (eg. jekyll) when people don't fill that value, so they don't have to think about "where can I find this value?". Of course, it can be overwritten.

Plugin needlessly indexes syntax highlighting in code snippets

I want to report a bug:

When I use jekyll algolia to index my blog, it chokes on one particular post, which has a lot of syntax highlighting. https://jtth.net/notes/choosing-ruby-or-clojure/. It doesn't continue, or move on, or anything, just dies.

What is the current behavior?

I get the error One of your records weights 37.36 Kb and has been rejected.

What is your expected behavior?

Indexing the post without ten thousand <span> tags for syntax highlighting non-linguistically queryable data. Or some way, at least, to exclude the post, or something.

Git repository to reproduce the issue:

Log file here: https://gist.github.com/jtth/0be2db8ab1e3780990cbf5a283cc235c

Ruby version used:

ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin17]

Jekyll version used:

jekyll 3.7.3

Check that the plugins works with jekyll-tagging

https://github.com/pattex/jekyll-tagging seems to be a popular Jekyll plugin for extending tags. It is not supported by GitHub pages, though.

jekyll-algolia should work correctly with jekyll-tagging, I just need to make sure tags are converted to strings if the plugin extended them.

Adding a loading bar indicator for large pushes

I want to suggest a feature:

We could add a [====== ] 66% loading bar indicator for large push.

What is your use case for such a feature?

When working on large websites, the initial push has to be done in several batches. This can take some time and no visual indication is given to the user during that time. Adding a loading indicator will be a better DX.

What is your proposed API? Is this a new option? A new behavior?

I suggest that if we detect that the push will be split in several batches, we should add an indicator. It should display the current number of records pushed and the total to be pushed, as well as the %.

algolia / jekyll-algolia Goto Github PK

jekyll-algolia's Introduction

DEPRECATED

Jekyll Algolia Plugin

Usage

Documentation

Installation

Basic configuration

Run it

More about the Community plan

Thanks

jekyll-algolia's People

Contributors

Stargazers

Watchers

Forkers

jekyll-algolia's Issues

I want to report a bug:

What is the current behavior?

I want to report a bug:

What is the current behavior?

Commands executed:

Ruby version used:

Jekyll version used:

I want to report a bug:

I want to report a bug:

What is the current behavior?

What is your expected behavior?

Commands to reproduce:

Ruby version used:

Jekyll version used:

I want to report a bug: before_indexing_each hook returns an error

What is the current behavior?

Ruby version used:

Jekyll version used:

I want to report a bug:

What is the current behavior?

What is your expected behavior?

Git repository to reproduce the issue:

Ruby version used:

Jekyll version used:

I want to suggest a feature:

What is your use case for such a feature?

What is your proposed API? Is this a new option? A new behavior?

I want to report a bug:

I want to report a bug:

What is the current behavior?

What is your expected behavior?

Git repository to reproduce the issue:

What is your proposed API? Is this a new option? A new behavior?

Putting all front-matter keys inside a frontmatter root key

Making the plugin have precedence over the front-matter

I want to report a bug:

What is the current behavior?

What is your expected behavior?

Git repository to reproduce the issue:

Ruby version used:

Jekyll version used:

Expectation

I want to suggest a feature:

What is your use case for such a feature?

What is your proposed API? Is this a new option? A new behavior?

I want to suggest a feature:

What is your use case for such a feature?

What is your proposed API? Is this a new option? A new behavior?

I want to report a bug:

What is the current behavior?

What is your expected behavior?

Ruby version used:

Jekyll version used:

I want to report a bug:

I want to suggest a feature:

What is your use case for such a feature?

What is your proposed API? Is this a new option? A new behavior?

I want to report a bug:

What is the current behavior?

What is your expected behavior?

I want to suggest a feature:

I want to report a bug:

What is the current behavior?

I want to report a bug: `before_indexing_each` hook returns an error

Putting all front-matter keys inside a `frontmatter` root key