e621 Configurator

This user script allows you to configure the user interface of e621 to your liking, by creating switchable profiles and custom view configurations for certain pages like posts, sets etc.
it is also possible to import and export created profiles in order to share them between multiple devices.
Since v2.0 it also includes a set suggestion feature, which suggest the most likely fitting set, for the currently open post.

A more detailed description with pictures can be found here

Features

• Set suggestion for posts
• Hide elements
• Move Elements
• Modify element CSS styles and classes
• Change link destinations
• Create new links / buttons
• Create custom tables in the set overview to better organize and group your sets
• Group sets in the add to set dialog
• Create, import and export profiles

Examples

A short list of simple changes that can be performed using this userscript can be found here

Tutorial

A tutorial on how to use the features can be found here

Userscript Installation

To use this userscript you will first have to download a user script manager like Tampermonkey.
Tampermonkey should work for all chromium based browsers (Google Chrome, Brave, Microsoft Edge, etc.)
If you are using Firefox follow this link to install Tampermonke.

After installing the suerscript manager, simply follow this installation link to install the userscript.

Alternatively, you can also visit the script's GitHub Page to see the source code and copy it manually.

Extension Installation

The browser extension only supports chromium based browsers at the moment, follow this link for installation instructions.

Bugs

In case you encounter any bugs, feel free to report them here

Feedback

I'm always open for suggestions and feedback ;)

Very interesting idea. I can see it being handy.

Fascinating project setup, though. I am still on the fence whether it'll make rolling out updates easier or more difficult.

bitwolfy said:
Very interesting idea. I can see it being handy.

Fascinating project setup, though. I am still on the fence whether it'll make rolling out updates easier or more difficult.

Thanks, I really appreciate it.

Updating the userscript itself should be relatively easy, the only problem is the chromium extension, because I had to restructure it in a way, which isn't supported by userscripts, due to the way they are injected.
I'll play around a bit and see what I can do, I'm not really satisfied with the code architecture myself .... That's what you get, if you start coding something very small and blowing it up far beyond its original scope :P

s87gmil said:
Thanks, I really appreciate it.

Updating the userscript itself should be relatively easy, the only problem is the chromium extension, because I had to restructure it in a way, which isn't supported by userscripts, due to the way they are injected.
I'll play around a bit and see what I can do, I'm not really satisfied with the code architecture myself .... That's what you get, if you start coding something very small and blowing it up far beyond its original scope :P

I haven't looked at the extension version, but there are several downsides to using the userscript as nothing but a loader for remote files.

• The @require files are cached, and the update interval depends on the user's settings. By default, it's weekly, but could potentially be set to "never". That means that any updates will be delayed - or might not reach users at all. Could be an issue if a site updates, and the script breaks.
• You are loading files from the main branch of the repository instead of from a specific tag or commit. This means that it's not possible to revert to an older version of the script.
• If the repository disappears for whatever reason, the script will stop working.

Effectively, what you have here is a "userscript as a service", which is really interesting.
If I were you, I would create git tags for every version, and @require files from that specific version. But that's up to you, of course.

But yeah, I know a thing or two about a project growing far beyond its original scope: https://github.com/re621/re621
Started out as a small project that lets you customize e621's navbar to your liking. 1500 commits later, it has grown into a massive toolkit - and an equally massive mess when it comes to code.

bitwolfy said:
I haven't looked at the extension version, but there are several downsides to using the userscript as nothing but a loader for remote files.

• The @require files are cached, and the update interval depends on the user's settings. By default, it's weekly, but could potentially be set to "never". That means that any updates will be delayed - or might not reach users at all. Could be an issue if a site updates, and the script breaks.
• You are loading files from the main branch of the repository instead of from a specific tag or commit. This means that it's not possible to revert to an older version of the script.
• If the repository disappears for whatever reason, the script will stop working.

Effectively, what you have here is a "userscript as a service", which is really interesting.
If I were you, I would create git tags for every version, and @require files from that specific version. But that's up to you, of course.

But yeah, I know a thing or two about a project growing far beyond its original scope: https://github.com/re621/re621
Started out as a small project that lets you customize e621's navbar to your liking. 1500 commits later, it has grown into a massive toolkit - and an equally massive mess when it comes to code.

Thanks for the suggestions,
I have absolutely no experience with userscripts and their update behavior, so you provided me with valuable insight.
It would probably be best to do more research in terms of userscripts and how to provide updates.
Till now, I have only developed software that was built and shipped, so updating basically meant shipping a new version and overwriting the old one ... Well can't hurt to learn new methods

v2.4

Set Suggestion Feature

The script now has a set suggestion feature, which attempts to suggest your most appropriate set for the currently opened Post.
Sets are suggested inside the "Add to set" dialog in descending order, according to the likeliness that it is appropriate for the post.
It is possible to directly add the post to the set using the "Add to suggested set" button inside the dialog, or to skip to the next suggestion, in case the suggested set isn't appropriate for the post.

How it works

The set suggestion works, by gathering the tags of all the posts inside your sets and assigning them different weights, depending on the percentage of posts with a certain tag inside a set.
This ensures, that tags, which are very common in a set are weighted higher than uncommon tags in a set.
Because all of your sets and the posts within them have to be loaded and evaluated, the set suggestion feature will take some time before it will work.
The loading times heavily depend on the amount of sets a user has and the amount of posts within them.
Post amounts loaded per set are dictated by the "posts per page" setting in the user's account.
After all the sets and posts have been loaded and evaluated, the data will be cached for 30 days, so the response times after the initial load are very fast.

I would thus suggest setting up the feature inside your chosen profile by checking the "Suggest sets" checkbox and entering your username, and waiting until a set is suggested after opening a post and waiting for 1-3min.
After this initial load, the set suggestions should appear almost instantly after pressing "Add to set" inside a post.

Technical Limitations

Sets will only be evaluated and cached, if they contain more than 5 posts.
This is necessary to prevent sets, that don't contain enough posts to make accurate predictions, from being cached and thus hurting the overall suggestion accuracy.
In general, the suggestion quality for sets with a small amount of posts and tags associated with it, is unreliable at best, due to the lack of relevant tags and the fact that the weighing of each tag is higher.

This is a tradeoff between suggestion quality and the possibility for small sets to be suggested.
I opted to lower the caching period for sets with less than 10 posts, so newer sets are evaluated more frequently and allow the user to steadily add more posts to the set, until the suggestion accuracy is high enough to be cached for a longer period.

Update the script

The script can directly be updated by clicking the following this link
More information and tutorials on how to use the script can be found here

v2.6

Similar Post suggestion Feature

When viewing a post set, a new "Suggested Posts" link was added to the sidebar under the "Related" section.
When pressing the link, the script will collect all tags which are relevant in the set (used in more than 75% of posts), and performs a search using these tags.
In theory, the search results should only include posts, which are similar to the posts in the viewed set.

How it works

The script will collect all tags of the current set which are used in at least 75% of all posts in the set.
When clicking the link, a search with all collected tags is executed, which will result in posts that are similar to the posts in the set.
Sets with a small amount of posts or posts without any similar tags, will result in a poor search result, due to the lack of similar and relevant tags

Update the script

The script can directly be updated by clicking the following this link
More information and tutorials on how to use the script can be found here