Have you considered popping cloudflare in front of the site? It could help with scraping and caching

On category update page (https://www.mangaupdates.com/series/[...]?act=change&item=categories), the [See the tag dictionary] button links to:
https://www.mangaupdates.com/series/categories.html (not found)
instead of:
https://www.mangaupdates.com/categories.html

Why do you think it's the UI/UX that matters for relevance? Personally, I find the UI quite usable and what I deem as UX issues can probably be addressed by relatively small, targeted changes. For me, MU started to lose relevance after removal of scanlator web site links, rise of centralized readers like MangaDex, official simulpub releases and apps like Tachiyomi - in other words, when it became easier to consume manga. MU is no longer about finding new releases. Not sure what MU can do about that at all, but the API is a step in the right direction, enabling integration with other services. Being the definitive English manga DB and community willing to keep the data up to date are the strongest points, these can be capitalized upon and should be preserved above all else. That said, other documenting projects, despite same strong points, do not necessarily fair too well (MobyGames, Discogs, WeightWeenies).

Last edited by Klaster_1 at 1:00 am, May 16 2022

Ooh, interesting. I'm not very tech-savvy even though I'm in the tech major lol. But I'm curious about those UI/UX plans, and maybe I can learn a thing or two from you guys.

So, What I want to ask, if MU upgrade its UI. Will it affect the loading of the website? I know, I know this is silly question but I'm curious since I never handle real websites (just yet). I really like the current MU because everything is fast and it saves my internet connection. Anilist/MD has a great UI, but I'm pretty tired of using it. 😂 *cough* when it comes to UX, definitely we need to consider its usability, right? I think some people feel the same way as me: manage reading lists with ease. Including its load stuff, etc etc.

Still, I agree with Kluster's opinion, at the same time I also want to see MU go the next level with its UI/UX as well. It can be tried with necessary consideration.

I'm all for a new UI/UX (although I'm completely fine with the current layout), but I do want to add that I hope you ultimately put whatever future decisions on that to a community vote/opinion share. I can think of several sites off the top of my head that have been thoroughly ruined by unsolicited UI/UX decisions, and really I don't want that to happen here.

Another suggestion would be to add a "site skin" option like many other forum-based sites employ that would allow users to continue using the legacy layout if they so choose. That is, of course, unless the programming involved in future UI/UX changes doesn't allow for this.

Last edited by Alimeru at 2:57 am, May 16 2022

Now that the site is API driven, we can leave the old UI version up, probably forever.

For UX, we mainly want to focus on how moderation is done. Lamb does a majority of the addition of new releases, and other moderation tasks, such as moderating series comments, reviews, user upgrades, etc. We need a way to reduce that effort. The fact that he's been able to keep it up for 16 years is amazing to me, but we need to move to a more user-moderated workflow, like Stack Overflow or Reddit. Lamb took some time to write down the rules he uses to moderate releases, series, groups, etc, and I'd like to create some automation to make that simpler to manage. This is the #1 critical thing we need to do, and we need to do it before the end of the year.

For UI, I'd like to at least modernize the UI by converting it to React/Next.js, and have a more event driven website. Some of the AJAX (cough) code that the site uses is from the mid 2000s. It doesn't even use a framework. It's straight up Javascript. I'd like to also convert the comment/forum system to use markdown, etc, or perhaps use a third party forum system. I'd also like to have a primarily dark mode.

Hopefully this clears things up.

This should be fixed now.

Are there any plans to release a more accessible ID map for the third party developers in the near future, or do you just expect people to scrape 200k ids while also IP banning them because they're apparently making the site slow?

Please keep the old URI scheme with the series-, group-, ...-ID's working. (Ideally indefinitely. Detecting bots trying to enumerate them might be easier after a while using the new scheme.)

There are probably tons of bookmarks and links to these URLs all over the internet, chat logs, forum posts, text files, etc. ...

There are no plans to do that. It probably wouldn't have been an issue if 15 different people didn't decide to all do it at the same time. We are a free site and have no source of revenue. We can't afford to increase our server resources to meet the demand.

So it turns out we're actually under a denial of service attack from some bots in Russia. Trying to deal with it now, but there are thousands of IPs.

Edit: Okay, I think I dealt with this batch for now. It was only about 150 IPs.

Last edited by Manick at 8:03 pm, May 16 2022

Is there anyway to allow to filter releases in

for blocked/hidden groups ?

I would like to implement the feature I'm missing on MU which is :

- showing the correct red number on my reading list if the latest chapter has been deleted (Return of the Frozen Player is in this case. The release 50 on MU has been deleted but it still shows the red number 50)

- showing the correct red number number on my reading list according to the groups blocked/hidden (I don't want a red number showing me the latest chapter is 70 when I've blocked the group publishing this chapter 70)

I want to use this: https://api.mangaupdates.com/v1/series/{id}/ratingrainbow and get the rating for a series but how can I find the ID for a series? Is there a way to query a series by name and get returned an ID?

I could solve this in three ways I guess:
1) Have a separate function to return the list of filtered groups
2) Release a v2alpha function that includes metadata for each group about whether it's filtered or not, similar to how the releases search works.
3) Don't include the group in the list if the request is made by a user who has the group filtered.

I guess, from a purist perspective, I want a user to see all the groups that are scanlating a series on the series page. If we take #3 route, then it will hide those groups for users on the series page. So, I don't really like that.

The #1 route probably isn't a great route either, mostly due to the fact that some users probably have thousands of filtered groups.

I think #2 is probably the best bet?