In #2523, I did a copy&paste error with
07d6e619cc
I used the global `search_enabled` config key instead of the correct
`bib_search` key.
This PR fixed it.
## The issue
Currently Altmetric and Dimension publication badge elements have
non-obvious attributes that hide badges when some conditions are not met
,e.g.:
```
data-hide-no-mentions="true"
data-hide-less-than="15"
```
resulting in seemingly strange behavior where badges are enabled in
`config.yml` but don't show up consistently, as reported in #2443 :
Altmetric badges don't display for some pubs.
## This PR
- removes these hidden nondisplay conditions in favor of more
predictable website behavior;
- adds documentation links to point users interested in customizing
badge behavior to the right resources.
This PR adds a simple filter/search functionality to the bibliography.
It can be used in two ways:
1. Simply enter a search term in the input box.
2. Send a search term via the `location.hash`, e.g.,
https://alshedivat.github.io/al-folio/publications/#mechanics
**Notes:**
- The search box is optional. It can be simply removed if anyone does
not like it.
- Searching via `hash` works without the search box. My idea is to use
this functionality to index all BibTeX entries via the `ctrl-k` search
and link them via their BibTeX key.
- Searching via `hash` could also be used to set static links on the
current page, e.g., to filter specific co-authors, venues, etc.
- I don't know much about the design of the input field. I simply reused
the newsletter box style.
- Entering a search term in the box does exact matching. No fuzzy
search, no AND/OR logic. I kept it very simple. Maybe anyone else wants
to improve it in the future.
- The search looks in all data in the BibTeX entry that is parsed via
`bib.liquid`. E.g., it is possible to search for BibTeX keys, titles,
authors, years, venues, abstracts, or whatever `bib.liquid` prints.
- I used a 300ms delay before starting to search on the input box.
- Entering search terms in the box does not update the location hash
(things could get complex otherwise due to automatically updating each
other...)
- If the filter does not find any match in a specific year, the year is
also made invisible.
**Screenshot**
<img width="935" alt="screenshot"
src="https://github.com/alshedivat/al-folio/assets/1998723/447003e2-c623-4de9-b2c5-2357117a7743">
Looking for feedback.
To reproduce the bug:
```bibtex
@inproceedings{Vaswani2017AttentionIA,
title = {Attention is All you Need},
author = {Ashish Vaswani and Noam M. Shazeer and Niki Parmar and Jakob Uszkoreit and Llion Jones and Aidan N. Gomez and Lukasz Kaiser and Illia Polosukhin},
booktitle = {Neural Information Processing Systems},
year = {2017},
doi = {10.48550/arXiv.1706.03762},
altmetric = {21021191}
}
```
The bug is
1. It seems to be some weird property of the liquid template that [line
252-254](8d82670ff1/_layouts/bib.liquid (L252-L254))
doesn't work at all. According to [this
post](https://stackoverflow.com/questions/59887447/liquid-how-to-assign-the-output-of-an-operator-to-a-variable)
and [this issue](https://github.com/Shopify/liquid/issues/236), liquid
doesn't support assign the output of operator to a variable nor a
ternary operator. So based on my console log, the value of
`entry_has_altmetric_badge` is always a string value of
`entry.altmetric` when altmetric is provided in bibtex.
```liquid
{% assign entry_has_altmetric_badge = entry.altmetric or entry.doi or entry.eprint or entry.pmid or entry.isbn %}
{% assign entry_has_dimensions_badge = entry.dimensions or entry.doi or entry.pmid %}
{% assign entry_has_google_scholar_badge = entry.google_scholar_id %}
{% if entry_has_altmetric_badge or entry_has_dimensions_badge or entry_has_google_scholar_badge %}
<div class="badges">
{% if site.enable_publication_badges.altmetric and entry_has_altmetric_badge %}
<span
...
```
Note that this could be problematic that a string in liquid is always
evaluated as true as long as it is defined regardless if it is "" or
"false".
[reference](https://shopify.github.io/liquid/basics/truthy-and-falsy/)
2. when altmetric is defined in bibtex, now the order of set attribute
to badge is eprint > doi > altmetric id > pmid > ISBN, and the badge
doesn't work when an arxiv doi is provided.
I think the expected behavior should be
1. as documented in CUSTOMIZE.md, only render the badge when the entry
is set to either "true" or the altmetric id. (It could also implement to
always render the badge whenever doi or other related attribute is set,
and set altmetric to "false" to disable it)
```md
- `altmetric`: Adds an [Altmetric](https://www.altmetric.com/) badge (Note: if DOI is provided just use `true`, otherwise only add the altmetric identifier here - the link is generated automatically)
```
2. if the almetric id is set, use it first.
Currently, on the [blog](https://alshedivat.github.io/al-folio/blog/)
page, clicking "older" and "newer" on the pagination at the bottom
direct you forward to links like `/al-folio/blog/page/2/` and backward
to `/al-folio/blog/`.
However, if you click on the `1`, `2`.. etc buttons, there is a
different behavior. The links now contain an `index.html`. For example,
clicking `2` leads you to `/al-folio/blog/page/2/index.html`. It is the
same content, just with a messier hyper link. Same with clicking `1`,
you are brought to `/al-folio/blog/`.
This fix creates a consistency among the hyper links in pagination.
For some unknown reason, all the `document.onreadystatechange = () => {`
checks stopped working. Thankfully, replacing them with
`document.addEventListener("readystatechange", () => {` fixed the
issues.
---------
Signed-off-by: George Araujo <george.gcac@gmail.com>
Fixes#2469. Separated `news` and `posts` from other collections in
search, since it caused duplicated entries. Also to ensure they are in
chronological reverse order.
Signed-off-by: George Araujo <george.gcac@gmail.com>
- updates `external-posts.rb` plugin, allowing the user to specify an
explicit lists of urls in `_config.yml` that are then displayed in the
blog feed as external posts
- 99% of the code in this change is written by gpt-4:
https://chat.openai.com/share/24432d24-36a7-4d6f-a5c0-d7e5142f68cd