Logo in thumbnail #258
Comments
|
the list of entries you see at a process runs during the build step that reindexes all the content on the site and sends it to algolia. the the site uses algolia's api to generate these dynamic views (search box drop-down and the list under algolia doesn't return all the attirbutes for each record, instead the returned attributes are defined in config.yaml under the key you can see in that configuration that algolia is supposed to be returning
or
I'm not sure what's going on. It's odd that the logo shows up on the entry page but not in the browse list. I had to fix a related problem with missing images in the image carousel on the home page a year ago. Here is how jekyll conditionally checks to see if a promotion exists and what image to use for it: Line 26 in 765fc0f I don't have time to figure it out right now but hopefully these clues help. |
|
Ok, this is how jekyll resolves potential logo files in the repo to the
I renamed your |
|
I think this commit is the key to the problem a76bac7 - we should experiment with reverting it / rewriting it. Maybe the uberimage field is clobbering the logo somehow? also the header is now showing up on your page after renaming it lowercase. so we should convert the paths to lowercase and deal with variations of the image extensions. |
|
great work so far @sjamesparsonsjr! I found another clue to the mystery of the missing logos in the 'browse' view after noticing that you got the logo for Allevi working (by uploading the logo as On 7-mar-2018 @jasonbobe created Allevi's initial Then at some point the netlify builds started failing. Three days ago, on 15-oct-2019, @sjamesparsonsjr added The builds were still failing so no updates were propagated to the production site and thus the logo didn't show up (I think). After fixing the bug breaking netlify's preview & build pipeline, #255 was the first commit/merge to trigger a successful build (netlify deploy log) for the production site. So it included the Allevi However, the Allevi
Even more weirdly, the reason it wasn't showing up seems to be because the
So either the browse view is actually gotting an out-of-date index from algolia, or something in jekyll like the image plugin is setting the wrong value for the logo's exension and passing that to algolia during the build process (in which case algolia is probably working fine). |
|
I am now uncertain about the API key we are using to access the algolia index. We use algolia's instantsearch js package in two places to fetch records from the algolia index when computing views: assets/js/browse_instantsearch.es6 & assets/js/autocomplete.es6.
Currently the secret key is set with the value of the Likewise the values for However, the api_key provided to the two instances of instantsearch above is different from
Gaby & I are both members of the algolia team that administers the diybiosphere algolia index, and since my algolia dashboard also displays a variety of other user's search api keys, I had assumed that the keys were for partionining api access by user, but would be accessing the same index. Now I'm not so sure. So I'm gonna set up |
configure instantsearch by reading algolia settings in _config.yml; increase default number for results per page from 10 to 100
|
set up This didn't have an obvious effect (everything still works as well as before), so I guess we can rule out the api keys as the problem. then I added some logging statements to the so I read some more about how It seems clear from logs that It runs after jekyll finishes building the static files for the site. To continue with this, it would be smart to start running jekyll locally so it is easier to inspect the generated static files... will the yaml frontmatter include 'logo' fields from the sibling image plugin? netlify build log w/ using
|
|
also, it sounds like jekyll-algolia is stagnating and may not be updated to be compatible with mmistakes/minimal-mistakes#2257 let's just switch to gatsby already. |
|
@sjamesparsonsjr I think I figured out the cause of this bug. the algolia indexing script was running on both production and staging builds. if the logo wasn't exactly the same for both, then sometimes the algolia index would have incorrect information in it (updating from staging) visible at master. to fix it, I created a so when previewing non-master changes, don't expect the search index to work properly. If this problematic, we can set up a second algolia index just for staging. |
On the website when I do a search, are the thumbnails generated from the logo file? I've uploaded a couple of logo's and they are loaded to the webpage but not in the thumbnail.
The text was updated successfully, but these errors were encountered: