Refactor code that depends on the destination wiki's platform in order
to support generic wiki platforms (e.g. Wikidot).
Redirection to the Main Page now uses the destination_content_path to
send users directly to the destination wiki's main page, rather than
using a different URL depending on the destination wiki's software.
The only remaining code that depends on the destination wiki's software
is the construction of the search path. This code now has a default case
that doesn't add any software-specific path to a constructed search URL.
This allows any wiki, regardless of the software it runs on, to be
added by putting its full search path in the "destination_search_path"
property of the redirect definition.
As a result of these changes, it is now possible to add redirects to
Wikidot wikis, by just defining the full search path in their redirect
entry's "destination_search_path".
Co-authored-by: SnorlaxMonster <snorlaxmonster@users.noreply.github.com>
Ensure all search engines use the same code to filter which search results are results for supported non-indie wikifarms. This also fixes an apparent oversight where Qwant was not redirecting Neoseeker search results.
* Handling when Google results use Google's middleman (google.com/url?q=)
* When handling middleman links, instead of replacing search result hrefs with updated links, we now add the updated link in a custom data-iwb-href attribute
* Better handling of special characters in page titles
* Instead of moving indie results to the top of Google search results, we now move indie results above the first non-indie (Fandom / Fextra / Neoseeker) result. If no non-indie result appears, re-ordering doesn't occur. This is to avoid moving less relevant results to the top, particularly for searches for generic terms.
* Improved Google filtering to account for when Google uses their own middleman link
For identifying non-standard search results, "div[jsname]" is unreliable as Google does seem to add it to some standard search results. Replacing with checks for attributes that are more specific to Q&A dropdowns + cards.
This check should be moved outside of the searchEngineSettings if statement, because the result of it should be applied regardless of the searchEngineSettings.
A suffix that is added to the end of article names before performing a search on the destination wiki. This is typically used when a multilingual wiki separates its languages by suffixes (e.g. /es, /pt, etc.). Team Fortress Wiki is an example that uses this.
Also alphabetized lists in manifests, by site name (not including subdomain).
List of added instances:
breezewiki.catsarch.com
breezewiki.frontendfriendly.xyz
breezewiki.hyperreal.coffee
breeze.mint.lgbt
breezewiki.nadeko.net
z.opnxng.com
breezewiki.woodland.cafe
A single Bing search result can often contain links to many different websites. Before, if any one of these links was a link to Fandom, the entire result would be disabled (even if the top-level result was an indie wiki). With this commit, only top-level (header) links are captured, and disabling CSS is not applied to "explore further" links.
Browser sync storage has a 8kb limit per item, which we are quickly approaching. Compressing our wiki settings JSONs reduces storage from ~7.3kb to ~2.4kb.
Renamed platform "doku" to "dokuwiki".
The software is named "DokuWiki", just like "MediaWiki".
The previous search path construction for DokuWiki wikis would fail for
wikis that put their page names in query parameters instead of the path.
For example, https://wiki.diceydungeons.com/doku.php
(note that this wiki is not currently supported by IWB).
The solution is to use "doku.php", which always renders as the main page
on DokuWikis, regardless of the URL structure, so can safely be used as
the base URL for searches.
However, to parallel MediaWiki wikis, which put "index.php" in the
wiki-specific search_path, I've moved "doku.php" to the definitions of
individual DokuWikis, so the JS now only adds query parameters.
SnorlaxMonster