The new site is finally close to release, and thus we'd like to pull attention to it while it's still easy to make some last minute adjustments. If you haven't yet checked it out have a look here at the introduction thread for a link to the page and what to expect from the beta itself.

There are also some other interesting changes coming to e621 that aren't just more modern and robust under-workings, but actually interesting to the end user.

1.) Lore tags will finally make an appearance
- as part of this we will also be adding transgender tags to complement the existing sex tags
2.) new uploading page
3.) searching for up to 40 tags at once

There will also be a few rule changes going live with the page, but those will be detailed in a future "The new e621 site is now live!" thread.

You can leave feedback to the beta itself either in this thread, or if you have actual bug reports / feature requests please leave them on the beta site's forum instead.

Lore Tags!

Lore tags will be made into their own category, and contain all information that might be relevant to the viewer, but can't be seen inside the image. This will include things like relationship status of the characters, canon gender (if differing from visible), transgender identity, incest related tags, and possibly more.

Since it's a new category, and a bunch of tags will be used we haven't used before, we'll be trying to consolidate and clean them up in this thread.

You can help us on our quest to find the best transgender terms to use for tags here in this forum thread.
Please be aware that we will be harshly enforcing the rules in that thread, particularly about staying polite and constructive.

As note in general: Lore tags is the first, locked, category. This means tags can't be moved into the lore category by non-admins. Thus any lore tag must be sanctioned by us before it can be used. This is to both ensure the tags don't become redundant, and that tags don't get fractured so far as to lose usefulness.

New upload page

This is rather simple but extensive: The new upload page will take the user more by the hand to ensure the basics are tagged properly

What about audio tags? Tag What You Hear.

I hope API (both itself and documentation) will be better.

The new upload form is neat, but it's also kinda annoying if you already know what you're doing, especially in that a user's personal list of "quick tags" is hidden and unusable unless they click "related tags," but only after having already entered some tags. If the tag box is blank, clicking "related tags" does not bring up quick tags.
And, as before, hitting "related tags" after having already entered a lot of tags floods the window.

As my quick tag list is more or less my first resort, this form makes getting to those tags a bit obnoxious. If there was even just a separate "quick tags" button that would be a considerable improvement.

Edit: Also, I don't suppose there'd be a way to make the upload form be able to display dimensions for files uploaded by URL like it can for direct uploads?

What about a ''follow specific tag'' notification? for example, If I follow the ''Furret, -rating:e'' tag, I get a notification each time there is a new furret sfw upload.

Also, is there a posibility to implement blocking users instead of adding them to the blacklist? because if they send me a message I still get the notification.

blitzdrachin said:
What about a ''follow specific tag'' notification? for example, If I follow the ''Furret, -rating:e'' tag, I get a notification each time there is a new furret sfw upload.

Also, is there a posibility to implement blocking users instead of adding them to the blacklist? because if they send me a message I still get the notification.

Please use an RSS reader and the atom feeds for watching specific tag searches. It's currently outside of scope and high on processing power to provide customized feeds for each user.

The new site allows for disabling dmails from all users but staff, but I will also look into improving support for blocking specific users within in.

For future people, please place bug reports and feature suggestions feedback on the beta forums so that I can keep it in one spot. It's easier for me and I don't have to keep crossposting between forums all day.

KiraNoot said:
Please use an RSS reader and the atom feeds for watching specific tag searches. It's currently outside of scope and high on processing power to provide customized feeds for each user.

The new site allows for disabling dmails from all users but staff, but I will also look into improving support for blocking specific users within in.

For future people, please place bug reports and feature suggestions feedback on the beta forums so that I can keep it in one spot. It's easier for me and I don't have to keep crossposting between forums all day.

Oki, thanks for answering :3.

NotMeNotYou said:
3.) searching for up to 40 tags at once

Yes! There's been times when I've been trying to find a specific image, forgetting artists name, so I have to search tags that I think would apply to the image... 6 isn't really enough to narrow it down to an easily viewable number. This will make doing things like that SOO much easier!

Wow, this is great news!

AoBird said:
I hope API (both itself and documentation) will be better.

We should make our own documentation. With blackjack and hookers.

On a more serious note, we will be able to do exactly that, so I hope to contribute to the documentation at some point.

I have a general question as to the lore tags. I'm not strictly against adding them, but I do remember a number of valid reasons given for why they weren't implemented before, and to my knowledge, there hasn't been anything said regarding how to deal with those issues. So that's what I'm asking, how those issues are supposed to be dealt with. For example:

If a character is stated to be a trans by the creator, but later on no one can find where they said that, what should happen to posts of that character with the trans tag? Or similarly, if a character appears ambiguous/androgynous and the creator says they're physically male (for the male_(lore) tag), and sometime later no one can find where they said that.

If a character is stated to be of a particular trans identity by the creator, then at some point in the development of that character's story, the creator decides instead they have a different identity, do all existing posts with that character need to be changed?

If a creator says a character is one thing (e.g. physically male, or a trans_man) without the character showing or saying anything, but much later on, the character shows or says something different (shows themself to be physically female, or states to be non-binary), and the creator doesn't give an explanation for the discrepancy, what should happen?

If a character or creator never explicitly states anything, but the story the character is part of clearly implies something. For example, natani, who the creator has never explicitly said is trans or not, and the setting the character is in doesn't seem to be one that would understand being transgender, but the story is clear that they were born female and have a male (or at least not-completely-female) identity. Further complicated by the fact that the character originally thought the non-female identity was magically-induced, but then shown to not be, the magic was just a scapegoat they held onto to explain feeling different as they grew up.

So I guess to distill the questions down: How do we deal with "lost" lore information? Are we expected to change preexisting posts if lore information changes/is retconned? How do we deal with inconsistencies between creator-declared lore and the story showing/declaring something different? Can lore information be taken from clear inference, or does it have to be explicitly spelled out?

Will there be a summary of API changes posted anywhere? The API page on the wiki of the beta site just says "The new API is currently entirely undocumented, but follows a similar structure to the old one."

How long will the old API be supported for?

mr_pacific said:
Will there be a summary of API changes posted anywhere? The API page on the wiki of the beta site just says "The new API is currently entirely undocumented, but follows a similar structure to the old one."

How long will the old API be supported for?

Just thought I'd link an earlier post I made, as it answers a bit if that:
https://e621.net/forum/show/281799

With the new api being on the new site, the old one isn't supported at all. I'm pretty sure all the URLs have changed, though they're pretty easy to find/guess.

The old method of changing tags should still work, with sending all the old tags and your changes, but anything using that method should be swapped to only send the tag differences, like I put in that post, though it's got a different name for the field, such as tags_diff, I'd have to double check what it's actually called.

Given it's planned to move the api to use a dedicated /api/ path, there's going to be more changes to it, hence why it's currently undocumented.

If you're planning to develop something with the api it'd be best to wait till it's finalised, unless you're ok with changing the code each time the api gets changed/updated with no documentation to work with.

Tags/artist way below the picture? To me it doesn't feel intuitive at all. Reminds me a lot of FA which is not a compliment. Current website is kinda old-school but perfectly functional at the same time.

Will we still be able to use the old website layout? Like maybe choose it in settings?

ConnoisseurOfYiff said:
Will we still be able to use the old website layout? Like maybe choose it in settings?

It's a completely different codebase so no, there won't be a way to swap back to this version.

Dogpanzee said:
Tags/artist way below the picture? To me it doesn't feel intuitive at all. Reminds me a lot of FA which is not a compliment. Current website is kinda old-school but perfectly functional at the same time.

I'm pretty sure that's only on mobile.

Dogpanzee said:
Current website is kinda old-school but perfectly functional at the same time.

Although the site works ok from a user's perspective the code's pretty old and hard to maintain. For example the new site's a lot faster on the backend/database side, which is one reason the amount of tags you can search with is being upped to 40, rather than 6.

Are logins disabled? I've searched both threads about the new site and don't see any mention of it. I know I'm using the correct password, but the beta site isn't having it.

CCoyote said:
Are logins disabled? I've searched both threads about the new site and don't see any mention of it. I know I'm using the correct password, but the beta site isn't having it.

You need to register an account on there, the beta's a separate site while it's still a beta.

When the beta becomes the current site all the data's getting wiped and being replaced with the current E6 data.

Pup said:
You need to register an account on there, the beta's a separate site while it's still a beta.

When the beta becomes the current site all the data's getting wiped and being replaced with the current E6 data.

Ahh, got it. Thanks for clearing that up!

Could you talk a bit about why it was decided to start from "scratch" (looks like it's still a fork of danbooru) rather than iteratively improve e621's current fork of danbooru?

Tags e.g. the addition of transgender tagging didn't need a new codebase or schema. A new upload page is the same effort to build regardless of if it's in the current e621 or a new from-scratch codebase.

Searching for up to 40 tags at once is nice, were there significant changes to the tag search engine?

All in all the site looks like a fine _start_ to something, but looks quite unpolished - and is missing much of the garnish the current site has (more spacing between sections, consistent font sizes, rounded corners around sections). It's hard to tell what the additional dynamic features will be.

I see references to typeahead for editing tags, but why not implement typeahead features in the search bar first? Surely that's going to receive 100x (conservatively) the use of the edit tags input.

I think the addition of the lore tags is great - that's a really sensible way of categorizing something like that.

dhelta said:
Could you talk a bit about why it was decided to start from "scratch" (looks like it's still a fork of danbooru) rather than iteratively improve e621's current fork of danbooru?

The codebase is old enough that it would have to be rewritten and all of the templates redone to bring them up to date with rails. So instead of spending time reinventing everything, it was forked from newer danbooru and customized back towards what e6 was. As hard as it is to believe, this was less work than trying to migrate the site forwards.

I'm not thrilled with every decision that danbooru has made since then, but I at least have a base that I can iterate on top of now instead of something that yes, very much did need to be rewritten entirely to modernize.

As much as everyone seems to hate how danbooru looks, it's something that can be worked on. The CSS for the site is a total mess with too much special casing and I did a best effort pass to try and bring it closer to how the site looked. But it's going to be an ongoing process to bring the consistency of the old site back into it full fold.

So in what order will the lore tags appear in relation to other tags?

I was thinking

Artist:
Character:
Copyright:
Species:
General:
Lore:

I'm thinking putting lore below general because lore tags aren't necessarily what's in the image.

I just hate how many new tags there are right now. I really do not believe we need 3 or more tags just for canine (canis, canid, canine), and there are more examples.

It's great we can finally search more than 6 tags, but then I'd also like to think the tagging can be less specific and extensive again. Have simple tags make a comeback.

''Lore Tags!

Lore tags will be made into their own category, and contain all information that might be relevant to the viewer, but can't be seen inside the image. ''

So basically what you're saying is that ''Tag what you see'' is just getting rid of. I mean, why go through the trouble of making it a whole new tagging category while it can just be put in the image description? And as a post above here explains... you really expect people to keep up with the lore behind the image till the end of time? Do you expect US to keep updating that stuff if things change?

I really don't see the point of lore tags. Most people, I assume, are just here for a quick wank, not for work.

Dazz-Senpai~ said:
I just hate how many new tags there are right now. I really do not believe we need 3 or more tags just for canine (canis, canid, canine), and there are more examples.

It's great we can finally search more than 6 tags, but then I'd also like to think the tagging can be less specific and extensive again. Have simple tags make a comeback.

''Lore Tags!

Lore tags will be made into their own category, and contain all information that might be relevant to the viewer, but can't be seen inside the image. ''

So basically what you're saying is that ''Tag what you see'' is just getting rid of. I mean, why go through the trouble of making it a whole new tagging category while it can just be put in the image description? And as a post above here explains... you really expect people to keep up with the lore behind the image till the end of time? Do you expect US to keep updating that stuff if things change?

I really don't see the point of lore tags. Most people, I assume, are just here for a quick wank, not for work.

There are more species part of the canis genus than just dogs, if that's not relevant to you you can ignore that, the server will take care of that for people who do care about it.

Lore tags are the only tags exempt from TWYS, we will not be getting rid of TWYS. Hence why they are their own category and not mixed in with the other tags.

What about cover previews on pools? I know it's not good to "judge a book by its cover" but I think it'll make finding new pools a lot easier, as you don't have to open every single one to know if it'll get your attention

NotMeNotYou said:
There are more species part of the canis genus than just dogs, if that's not relevant to you you can ignore that, the server will take care of that for people who do care about it.

It does matter a bit, though. If someone's uploading a dog- or wolf-like thing, for example a picture of zacian or someone's generic furry OC, how many people will know whether canine, canid, or canis is more appropriate? How many people will know the difference? If the number of people who know and care to fix those tags are low, and taggers just randomly pick what they feel is right, it does introduce searchability problems.

Like, if I'm looking for wolves and dogs and search 'canine', how much am I going to miss because some things were tagged canid instead? And if I search for canis, I'm going to miss a number of wolf and dog breeds, whereas if I search canine, it'll include non-dog/wolf animals like foxes. Furries in particular aren't known for having strongly defined characteristics for their depictions of canines, leading to more generic tags being used often instead of actual breeds. And when it's anyone's guess what tag an uploader will use, it does get in the way of searchability if there aren't enough people to fix it.

Watsit said:
It does matter a bit, though. If someone's uploading a dog- or wolf-like thing, for example a picture of zacian or someone's generic furry OC, how many people will know whether canine, canid, or canis is more appropriate? How many people will know the difference? If the number of people who know and care to fix those tags are low, and taggers just randomly pick what they feel is right, it does introduce searchability problems.

Like, if I'm looking for wolves and dogs and search 'canine', how much am I going to miss because some things were tagged canid instead? And if I search for canis, I'm going to miss a number of wolf and dog breeds, whereas if I search canine, it'll include non-dog/wolf animals like foxes. Furries in particular aren't known for having strongly defined characteristics for their depictions of canines, leading to more generic tags being used often instead of actual breeds. And when it's anyone's guess what tag an uploader will use, it does get in the way of searchability if there aren't enough people to fix it.

Yeah just ''canine'' should include just all.Stop the cluttering of tags. Like I said, there are way more examples of tags that are highly unnecessary.

Watsit said:

When in doubt, be vague

Watsit said:
I have a general question as to the lore tags. I'm not strictly against adding them, but I do remember a number of valid reasons given for why they weren't implemented before, and to my knowledge, there hasn't been anything said regarding how to deal with those issues. So that's what I'm asking, how those issues are supposed to be dealt with. For example:

If a character is stated to be a trans by the creator, but later on no one can find where they said that, what should happen to posts of that character with the trans tag? Or similarly, if a character appears ambiguous/androgynous and the creator says they're physically male (for the male_(lore) tag), and sometime later no one can find where they said that.

If a character is stated to be of a particular trans identity by the creator, then at some point in the development of that character's story, the creator decides instead they have a different identity, do all existing posts with that character need to be changed?

If a creator says a character is one thing (e.g. physically male, or a trans_man) without the character showing or saying anything, but much later on, the character shows or says something different (shows themself to be physically female, or states to be non-binary), and the creator doesn't give an explanation for the discrepancy, what should happen?

If a character or creator never explicitly states anything, but the story the character is part of clearly implies something. For example, natani, who the creator has never explicitly said is trans or not, and the setting the character is in doesn't seem to be one that would understand being transgender, but the story is clear that they were born female and have a male (or at least not-completely-female) identity. Further complicated by the fact that the character originally thought the non-female identity was magically-induced, but then shown to not be, the magic was just a scapegoat they held onto to explain feeling different as they grew up.

So I guess to distill the questions down: How do we deal with "lost" lore information? Are we expected to change preexisting posts if lore information changes/is retconned? How do we deal with inconsistencies between creator-declared lore and the story showing/declaring something different? Can lore information be taken from clear inference, or does it have to be explicitly spelled out?

As a rule of thumb we'll go with whatever source is credible, and relevant to that image. Retcons will probably be honored if the artist / owner wishes so, not so much if some new information possibly is gleamed from a story itself.

If something is no longer accessible we'll likely only honor information from before the confirmed deletion.

KiraNoot said:
The codebase is old enough that it would have to be rewritten and all of the templates redone to bring them up to date with rails. So instead of spending time reinventing everything, it was forked from newer danbooru and customized back towards what e6 was. As hard as it is to believe, this was less work than trying to migrate the site forwards.

I'm not thrilled with every decision that danbooru has made since then, but I at least have a base that I can iterate on top of now instead of something that yes, very much did need to be rewritten entirely to modernize.

As much as everyone seems to hate how danbooru looks, it's something that can be worked on. The CSS for the site is a total mess with too much special casing and I did a best effort pass to try and bring it closer to how the site looked. But it's going to be an ongoing process to bring the consistency of the old site back into it full fold.

So... how close did you get to mimic/emulate e621's current appearance with the new coding? 90%?

Casanova said:
So... how close did you get to mimic/emulate e621's current appearance with the new coding? 90%?

https://beta.e621.net/

Okay, I poked around the beta and noticed a few annoyances:

• A way to disable the responsive design / mobile view would be really nice. Either when fed a desktop useragent (mobile browsers with a "view desktop site" button do this), or via a link in the menu.
• Under the Posts tab, Popular isn't linked but is instead buried under "More >>"
• The burger menu auto-collapsing is super annoying if you want to get to any sub-category below the main tabs. In mobile it takes two page loads to get to Posts->Upload or Artists->Avoid Posting (if anybody checked that before, they definitely won't now!). Consider reorganizing the burger menu as a floating dropdown?

foobar said:
Okay, I poked around the beta and noticed a few annoyances:

• A way to disable the responsive design / mobile view would be really nice. Either when fed a desktop useragent (mobile browsers with a "view desktop site" button do this), or via a link in the menu.
• Under the Posts tab, Popular isn't linked but is instead buried under "More >>"
• The burger menu auto-collapsing is super annoying if you want to get to any sub-category below the main tabs. In mobile it takes two page loads to get to Posts->Upload or Artists->Avoid Posting (if anybody checked that before, they definitely won't now!). Consider reorganizing the burger menu as a floating dropdown?

There is a link to disable the mobile mode at the bottom of every page. And the site fully respects if mobile browsers request a desktop version. Sniffing user agents and using other distinctions to detect mobile browsers are not used because these are intentionally broken. So the site is using the browser creators sanctioned method of deciding when to display a mobile site.

I like the idea of a more responsive menu, but the site currently doesn't have a full menu hierarchy on the page, same with the current site(the one you're using) the sub items are specific to if you're already in a section or not. I'll look into generating a full menu as a later task.

Im just gonna assume the background themes will make a return when its out, it feels really bland and flat just being 2 solid colors.

Besides that i think its fine, more streamline than the old site (although i will admit as a long time user and artist the change is gonna be hard on the eyes haha)

The only thing im concerned with that isnt nit picky: cant say i agree with the giant next/prev bar above every image, feels like it gets in the way of the art and would do better underneath it.

To me it looks perfect. The two things I most wanted are in. Auto-completion of tags in the search box and being able to go to the next image in the results once tags are searched.
Well done.

KiraNoot said:
There is a link to disable the mobile mode at the bottom of every page

Where?

Thoughts:
Can/will you alter the sidebar to be closer to its current width? As it is on the beta, the sidebar text is a larger font and linebreaks might get out of hand.
Will the Random Page function be unhidden when you roll this out?
Will the ugly "E621 Beta" text at the top be moved to the next line of the menu like it is on the current site?
Will you bring back the collapsing Sources section and colored ratings on the post page?

foobar said:

• Under the Posts tab, Popular isn't linked but is instead buried under "More >>"

It looks like there's the "Hot" feature, but that searches by "order:rank" rather than "order:score". Is there a difference?

backsash said:
Im just gonna assume the background themes will make a return when its out, it feels really bland and flat just being 2 solid colors.

Besides that i think its fine, more streamline than the old site (although i will admit as a long time user and artist the change is gonna be hard on the eyes haha)

The only thing im concerned with that isnt nit picky: cant say i agree with the giant next/prev bar above every image, feels like it gets in the way of the art and would do better underneath it.

For that matter, if you're going to have that bar there, even when you aren't searching by tag, it'll cause problems if it's kept too close to the prev/next bar for pools and comics.

Dazz-Senpai~ said:
I just hate how many new tags there are right now. I really do not believe we need 3 or more tags just for canine (canis, canid, canine), and there are more examples.

It's great we can finally search more than 6 tags, but then I'd also like to think the tagging can be less specific and extensive again. Have simple tags make a comeback.

''Lore Tags!

Lore tags will be made into their own category, and contain all information that might be relevant to the viewer, but can't be seen inside the image. ''

So basically what you're saying is that ''Tag what you see'' is just getting rid of. I mean, why go through the trouble of making it a whole new tagging category while it can just be put in the image description? And as a post above here explains... you really expect people to keep up with the lore behind the image till the end of time? Do you expect US to keep updating that stuff if things change?

I really don't see the point of lore tags. Most people, I assume, are just here for a quick wank, not for work.

Yeah, I pretty much feel the same way.. I'd take it another step and ask why lore tags are really needed at all..? It feels like opening a whole can of worms that is simply not needed. And that's in the best of cases! I have a bad feeling this is going to turn into a clusterfuck and lead to many headaches down the road.

Penguinempire-Dennis said:

It looks like there's the "Hot" feature, but that searches by "order:rank" rather than "order:score". Is there a difference?

Iirc it also takes into account how long a post has been up; it counts votes per unit of time and is therefore a fairer comparison between the popularity of new and old posts.

By estimation, when will the beta version be released?

AlexYorim said:
By estimation, when will the beta version be released?

There has been rough estimates for around this time, but as we are relying on certain individuals and it's computers and code that's being handled, it will be valvetime™

Hopefully asap as the new site does operate really well already and it is much easier to catch stuff in day-to-day use.

Can I have a copy of the old CSS, please? I strongly dislike the new design (it feels too flat and minimal and... off) and would like to restore the old design as much as possible with custom CSS. I would've liked advance notice of the redesign so I could've prepared for it by saving the old CSS.

inb4 thread locked because the beta's out now

Favorite part is 'nearing completion' and 'launch buggy and broken and missing a ton of features' is synonymous nowadays, and if it changes from old it most definitely regressed in a lot of ways
Steam, Epic, Warcraft 3, and now E621

They've at least been working fast to fix the stuff at least.

neonmarker said:
Can I have a copy of the old CSS, please? I strongly dislike the new design (it feels too flat and minimal and... off) and would like to restore the old design as much as possible with custom CSS. I would've liked advance notice of the redesign so I could've prepared for it by saving the old CSS.

I found it at archive.org.

foxybomb said:
inb4 thread locked because the beta's out now

TBH, it probably should be?