Today is National Banana Day! 🍌 In honor of this nutritious and portable fruit, we're bringing you a whole bunch of bug fixes!
You might even say we went a bit bananas with our recent bug fixes—but maybe not, since you probably don't want me to make more banana jokes (I don't either, but I can't seem to stop myself).
Since there are so many bug fixes, I've grouped them so you needn't be faced with a wall of text.
File Library:
- We had an issue in the File Library that was giving some folks false "no results found" results. This happened when you made a search, went to the second page of results for that search, and then searched a different term from there. If that second search term only had one page's worth of results, then you would be told there were no results. It was happening because it was looking for results on the second page you were on. Anyway, it doesn't do that anymore! Woo! You'll get the existing results for File Library searches no matter which page number you start the search from.
- Some folks may not have been seeing their custom favicons load on their browser tabs for a while. This was happening for customers who had secured file libraries, as the favicon was getting an extra https: when the page rendered. We've fixed this so the extra https: is gone so the beautiful favicon you've added to your knowledge base should properly display (if you've chosen to add one).
Revisions/versions:
- We had a strange bug come up with newly activated article versions. The first recent revision made to a newly activated version wasn't showing in the 'recent revisions' area when the new version was created from a copy of a previous version. Once you saved a second change to the article, it registered one recent revision, but if you clicked into the revisions, you could see the previous revision as well. So, all was not lost, but it was a confusing experience for folks. Even just explaining it here got a little confusing! We've corrected that behavior now, so you'll be able to see the correct amount of revisions that were made to any version.
- The link to revisions when viewing inactive versions wasn't working properly, preventing you from clicking to see the recent revisions of inactive versions of an article. The links have now been formed correctly, and you can wax nostalgic about the previous revisions of your inactive versions to your heart's content (aka you are now able to look at the recent revisions of your inactive versions).
Right-hand editor related articles area acting up, KB access dropdown woes, and an SEO improvement:
- When creating/editing an article, there was some funny business happening when adding multiple related articles. If you added more than one related article to an article before hitting save, the previously set related article was appearing in the search field. You had to delete that text before you can search for another article to add. This has been fixed, so now if you click to add a new related article, the search field will default to blank.
- Remember last week when I bragged about how we made the knowledge base dropdown, search, and view KB area fixed at the top of the left-hand navigation? Well, that created a problem with the dropdown menu to access the other KBs in your account—it was cut off by the fixed container. Oopsie daisy! This has been corrected, so there's no more cutoff and you can easily access any KB in your account via that dropdown, no matter how many you might have.
- For those of you with partially or fully public knowledge bases using Google to monitor site performance: we were allowing Google to index all search result pages, and it was logging each "no results" search and empty pages as "Soft 404s". (This is a designation Google makes when a page isn't a true 404 but doesn't seem to contain meaningful information.) Thanks to a customer report, we learned of this oversight. We've added X-Robots-Tag: noindex to all search results pages to prevent search engines from indexing these pages and to remove these extra noisy reports from your analytics. If you were seeing search results URLs show up in your analytics as Soft 404s, you can request that Google re-crawl those pages, or your whole site, to resolve any remaining issues.
API things:
- We started to cache repetitive API calls to improve your KBs performance. Well, we went a little too far and apparently were double-caching API calls made in snippets. Now it's caching just once, as we'd intended, which should speed up those updates even more. 🙂
- API keys created or edited to have no permissions were making the API page throw an error. We've fixed that now so the page will properly load and allow you to edit those API keys.
Our honeypot is back in business:
- As you might have seen in our in-app alert or release notes, we had an issue where our home-rolled honeypot rejected some customer messages sent via our widget. When we discovered the problem, we turned the honeypot off and got to work finding the cause of the problem. The issue was with the widget methods you can use to open directly to a particular tab. We've fixed the issue. Now our honeypot is back in action on our widget, better than ever, and super well-tested! And if you did miss the previous notice about it, rest assured that the issue only affected our own widget/contact form, not those of any customers.
We sent out an email heads up about this a couple of weeks before the change went live - but the change I outline below requires a longer-winded explanation, so I saved it for the end. Here goes!
Automatic Needs Review status will actually change the status now:
Previously, when you've used the "Automatically set articles to 'Needs Review' if older than the below date" option in Settings > Basic, we weren't actually updating the article's publishing status behind the scenes.
Instead, when you viewed published articles, we'd do the calculation when you viewed the Articles, article editor, or Manage pages and alter the status we showed you in the browser only.
We now have a scheduled job to fully update the status on a nightly basis when this setting is applied. Articles meeting this criteria will be set to "review" status instead of "published" in the API. With this change, the status you see in-app and the status behind the scenes will match.
If you only use the KnowledgeOwl app itself (not looking at things in the API), things will look the same as they always have: articles last updated after that last date will still show as "Needs Review."
If you've been using the API with this setting, all of the articles calculated as "Needs Review" in app were still marked as "published" status in the API. Now their status is changed to "review."
If you're using an API snippet or making API calls to pull articles, please review those calls to be sure they can handle both "published" and "review" status articles (if appropriate).
That's it for this week! If you have any questions about any of these please let us know.
And if it's warm where you are and there's an ice cream shop nearby, please have a banana split for me—those things are the best! 😋
un-fun (for me) bonus fact: I developed a banana allergy in my late 30s. It started with a wee tummy ache, then evolved into me getting super ill in public last time I ate one. It's a huge bummer of course because well, as mentioned above: banana splits are the best.
