I think what’s happening here is that 烝 is considered the phonetic component of 蒸 in Japanese, and then 丞 the phonetic component of 烝, and the lack of 烝 on WaniKani is causing a break in that chain.
Nah, it’s the same radical, just a different name. If you enter “shark” into the WaniKani search box, only Coral comes up as a result.
Okay, I just said that because this forum post from 2017 says that the Shark radical is 烝, just like the Keisei script says on the steam page.
Yeah, they must have changed the radical at the same time they changed the name. I tried to search for more information on this, and all I turned up was a single question about it, by… uh… by me. And I don’t seem to have received an answer.
This does not seem to work for me, unless I am missing something very obvious.
I installed it on Chrome on Windows first, nothing changed about WK for me. Just to make sure, I did the same on Firefox, also nothing.
To test it, I clicked around a bit, hoping to find new phonetic info. I for example went here:
https://www.wanikani.com/radicals/sheep
https://www.wanikani.com/kanji/%E7%BE%8A
https://www.wanikani.com/kanji/%E9%A4%8A
https://www.wanikani.com/kanji/%E6%B4%8B
Though these are clearly phonetically related and all pronounce よう, none of them show phonetic information in either browser. Nor did anything else I tried.
The Firefox is especially strange, as it’s up-to-date and I don’t use it for anything else, so no other extension is listed as installed except Tampermonkey.
Could anybody help me?
Are you getting any errors in the console on these pages related to this script? (press F12, you might see several errors in general but not all will be from the script)
It sounds like you’ve just installed it so I assume the version is the latest one (should be 1.8.32)
Oh strange, JQuery isn’t defined for you. It’s still working fine for me so I’m not sure what the cause of the difference would be. Is your Open Framework up to date as well (version 1.1.9)? If you type $ in the console while on this page, do you also get undefined? What about window.jQuery?
I just typed it as you wrote it. 
Hi, you gave me the right hint - I didn’t have WK Open Framework installed. Now it works on Firefox. 
Thank you.
I think I’ve found a bug. On the Shining kanji https://www.wanikani.com/kanji/昭 the script is only showing the part that says “The kanji 「昭」 is used as a phonetic mark in other compounds!” It’s not showing the section that says “was created using semantic-phonetic composition!” which you can see at Beckon https://www.wanikani.com/kanji/招. Notice how on Beckon, Shining shows up in the list of other kanji using the same composition.
I don’t understand. I clearly see this section immediately after the “The kanji 「昭」 is used as a phonetic mark in other compounds” section. in the page https://www.wanikani.com/kanji/昭
Am I missing something?
Edit: the below is incorrect, the second section about its own composition is shown if you expand the info by clicking the down arrow next to the eye icon.
I don’t believe I’ve ever seen the script have both of those sections. Basically, if it is used as a phonetic mark then the information about its own composition is left out. Can you find any examples where both sections are displayed?
I believe they are trying to say that the first kanji should also have a section saying it was created using composition (whereas it currently only says that it is used as a phonetic mark in other compounds).
Having compared the two you mention, I notice the following:
https://www.wanikani.com/kanji/%E6%8B%9B
Both “shining” and “beckon” were formed from “call.”
https://www.wanikani.com/kanji/%E6%98%AD
“illuminate” was formed from “shining.” Since it appears completely in another compound, it references where it also appears.
However, “beckon” appears not as compound in other kanji. Hence its section refers back to the compound it was formed from. Which also appears in “shining.”
As others have remarked, either you seem to get the section that shows where something is used elsewhere, otherwise the one where it derives from itself, and finally nothing if neither applies. But not both. I don’t think that’s a bug.
Of course at times it would be useful to find the chain back even if something is used entirely elsewhere, but that’s not necessarily a bug, more like a preference, I guess?
Yes see here. https://www.wanikani.com/kanji/昭 This is the item page I was commenting on.
That kanji does not have a section talking about its own composition. It only mentions that it is used as a compound in other kanji. PeterAhlstrom was saying that it should have both sections, but I remarked that I have never seen this be the case.
Sorry, I’m an idiot and completely forgot that you can expand info with this script. Apologies.
Thanks to @prouleau I was reminded that there is the ability to expand info for an item. It is a sticky toggle, so if you expand it once on an item it will be expanded for all items after until you collapse it. The information you were seeking is in this expanded section. Tagging @DerKastellan as well for this updated information.
The one time I don’t click every button just to find out what it does… amazing. 
Hahaha, wow. I have actually never seen that entire row of buttons before. How on earth did I miss that?!
Found I think an actual bug this time. On the page for Demand 需, it says it’s used in 濡 Get Wet, which has a striped background indicating it is not in WaniKani. But 濡 is in WaniKani as Wet. Or…does the striped background just mean that WaniKani isn’t using the on’yomi and is only using the kun’yomi on this kanji?
This is less a bug and more like a consequence of the database(s) that Keisei uses not being updated with changes to Wanikani. Basically, at the time this script was made that kanji wasn’t on Wanikani, but at some point it was added. However, the script doesn’t know about this, so it thinks it still hasn’t been added. The script would need to be updated to fetch data using open framework and use that to determine if a kanji is in WK or not (and also to update readings; sometimes you will find that the script styles a reading as not in WK but it is, indicating that they added it or changed the primary reading at some point).
It’s on my todo list to eventually update Keisei with this functionality in my own fork of the repo and then submit a pull request for it. But I don’t know when I’ll get around to that.
