New Danbooru Functionality

Now that the DText allows us to link to different parts of a page (forum #119589), I've been experimenting around on the wiki, creating a Table of Contents structure.

Check out the Girls und Panzer wiki page to see what it looks like. I added both forward links to different parts on the page, and reverse links back to the Table of Contents (indiciated with a "^"). Request for comments on how it looks, and if there are perhaps better mnemonics or visualizations to use. Thanks.

Edit

• (2016-10-19) Changed the title for all new functions to be reported in one thread
• (2016-12-03) Changed category of thread to "Bugs & Features"

Note that albert just changed the way DText header links work, although it's not deployed yet. Now `h1#blah. header` generates the id `dtext-blah`. This was done to prevent clashes with ids already in use by the site (issue #2659).

But yeah, I think it's a good idea. There are a lot of tag_group:* and list_of_* pages where this could be useful.

Does that mean that the URL links now need to be modified, but not the header tags...?

So...

http://danbooru.donmai.us/wiki_pages/37251#intro

...would need to become...

http://danbooru.donmai.us/wiki_pages/37251#dtext-intro

...but that the header would still remain....

 h4#intro. Intro

Is it too late to change the "dtext" prefix into something more descriptive, like "header"?

This feature is a good addition. I could have sworn this feature existed before, though.

Anyway, I like this and I'm glad it's been implemented.

BrokenEagle98 said:

Does that mean that the URL links now need to be modified, but not the header tags...?

Yes, exactly. It's not very intuitive, but I don't think there's any great way of handling it. Anyway, the change is now live.

Also I like the table of contents idea, but I realized it's possible to generate these automatically, so I added that to my userscript. It automatically adds a table of contents on every wiki page with more than a few headings. But on some pages it's not so useful, so in the long run it might make more sense to add them manually where appropriate. I just did this to get a feel how it'd look on various pages across the wiki.

I was thinking the same thing as far as adding TOC's automatically. However, that requires a well organized header structure for that particular wiki entry, using lower number headers for higher level topics and vice versa. If instead the header numbers are chosen willy-nilly, then the table of contents produced wouldn't make a lot of sense.

I think most wikis do a decent job of following a logical structure - h4 for headings, h5 for sub-headings, h6 for sub-sub-headings. If they don't, they deserve to be fixed regardless.

Speaking of headings, the h1-h3 headings are almost never used. I can't speak for everyone else, but the reason I don't use them is that they put too much white space before and after the heading. See the help:dtext wiki for an example of what I'm talking about. That may even be the way they're supposed to be, but I'd rather they didn't have so much padding, especially since there's really no other way to change the size of the font with DText.

Wow, yeah, that padding is ridiculous. Honestly I think no one ever noticed. Should be submitted as an issue, it'd be a trivial fix.

To all Builders...

A new commit just went live that allows for deleting/undeleting and locking/unlocking of wiki pages. Now instead of purging the wiki page like before, it just sets a flag, similar to artist deletions.

BrokenEagle98 said:

To all Builders...

A new commit just went live that allows for deleting/undeleting and locking/unlocking of wiki pages. Now instead of purging the wiki page like before, it just sets a flag, similar to artist deletions.

Should we still use topic #7690 for completely pointless wikis like recent sub:ira-bit? (quite common mistake)
And somebody update help:users please.

Updated help:users. Edited the builder section to organize it a bit better too (should probably update the other levels also). The new API limits need to be documented as well, but those are probably still in flux.

Re: the Pointless Wikis thread, I guess it can still be used for requests by Member-level people, or if a deletion somehow requires discussion. Otherwise I say just clean stuff up as necessary; that was the point of this update, so we don't have to beg mods to clean up trivial things.

I like the way you organized help:users. After things settle down, the whole page could use a revamp.

BrokenEagle98 said:

To all Builders...

A new commit just went live that allows for deleting/undeleting and locking/unlocking of wiki pages. Now instead of purging the wiki page like before, it just sets a flag, similar to artist deletions.

Is it possible to make it so that deleted wikis don't appear under Recent Changes?

Yes, although it might be better to instead display the status, similar to how Artists work. That way, it can easily be seen which wikis are being deleted, so if there was an error, it can be discussed with the deleter or in the open forum... Thoughts?

In the navbar on wiki pages there's a Search option that takes you to a search form. There you can choose order by date and hide deleted to get this listing. This is could stand to be improved though, it's not at all obvious or convenient to use.

I think the Recent Changes list in the sidebar ought to show all changes, so deletions don't go under the radar, while the full listing (/wiki_pages?order=time) should have a search form at the top for filtering out deleted wikis if you so choose. It should be similar to the search forms the /tags and /pools pages have.

Also I notice that when you do a tag search for an aliased tag that has a deleted wiki, the wiki tab still contains the deleted wiki. See: time_stamp. It should probably show the wiki for the aliased tag instead.

Just as a broad announcement...

A new commit just went live today that acts as a form of super-implication for cosplay tags.

Basically, tagging "character_(cosplay)" will also add the "character" and "cosplay" tags.

This came about as a result of the discussion in topic #13367.

Updated help:autotags. Autotagging of animated pngs was added a little while ago too, can't remember if that was announced.

With the latest commit, the upload notice and flag notice are now settable via the wikis, namely with help:flag notice and help:upload notice respectively.