1
0
Fork 0
forked from OpenNeo/impress
Commit graph

1485 commits

Author SHA1 Message Date
7688f21eeb Tweak the NeoPass announcement box's orange down
Idk, I think the previous text color was a smidge too low-contrast, and
we can afford to decrease the border's loudness, too.
2024-04-27 14:25:58 -07:00
05155507c4 Update NeoPass announcement to link to our new survey
I refresh the image and UI color here to draw attention to the change!
I also delete the `neopass-thumbnail.png` image, since it's no longer
used anywhere anymore, but I would not be surprised if we want it back
someday and need to revive it from history!
2024-04-27 14:19:27 -07:00
156cabbab4 Add shadowban mechanism for closet lists
Simple enough to start! If `shadowbanned: true` gets set on a user,
then we show a 404 instead of the actual list page, *unless* you're
logged in as that user, or coming from a known IP of that user.

This isn't a very strong mechanism! Just something to hopefully
increase the costs of messing around with list spam.
2024-04-20 20:57:15 -07:00
4ae5acfdc3 Disallow email addresses in closet list descriptions
Just another attempt to communicate the rules!
2024-04-16 17:04:31 -07:00
1cbcb5bcd6 Add trade warning to closet list form
Just a lil blurb to make sure it's clear that NC sales and stuff are
forbidden! I imagine the people doing it know this, but I want to make
sure we're being explicit, in case there's any element of
miscommunication.
2024-04-16 16:53:30 -07:00
fa202af26d Time out if manifest loading takes too long
This hasn't been causing issues as far as I know, I just noticed
*months ago* that I forgot to do this, and have had a sticky note about
it on my desk since then lol.

I tested this by temporarily setting the timeout to `0.5`, and watching
it fail!
2024-04-16 16:18:51 -07:00
f8e4e83723 To "fetch" the image hash of an image hash name, just take off the @!
A further optimization, this lets us use the image hash as the new hash
for the pet type if it would be useful! (whereas before this change,
we'd dip into `fetch_metadata` and just get back `nil`, which was okay
too but a little bit less helpful!)
2024-04-16 15:57:39 -07:00
3ea0842f00 Skip loading image hashes for "pets" that start with @
This is an optimization on top of 9d8f035, in which we skip the network
request altogether in this case that we know will and should fail!
2024-04-16 10:10:28 -07:00
9d8f035360 Oops, stop crashing when modeling "pets" that start with @
Ahh, we recently added a step to pet loading that sends a metadata
request to `PetService.getPet`, which is now (in a sense, correctly!)
raising a `PetNotFound` error when we try modeling with a "pet" that
starts with `@` (a trick we use in situations where we can get an image
hash for a modeling situation, but not an irl pet itself).

In this change, we make it no longer a crashing issue if the pet
metadata request fails: it's not a big deal to have a `PetType` have no
image hash or not have it be up-to-date!

In the next change, I'll also add an optimization to skip fetching it
altogether in this case—but I wanted to see this work first, because
the more general resilience is more important imo!
2024-04-16 10:03:36 -07:00
40bfd42af6 NeoPass launch message on homepage
Some cute logged-in-user differentiation uwu
2024-04-12 07:22:25 -07:00
aa0b376a12 Clarify NeoPass explanations
In particular, we got feedback that it was surprising to not get to
check which NeoPass you wanted to use, and that the permissions were
never prompted again. I figure let's err on the side of ample clarity!

As part of this, I've added the new `external_link_icon` global helper,
which embeds an SVG from Chakra UI. That's just the convenient place I
know to grab that icon, and I did it this way instead of an `img` tag
because that enables the `currentColor` thing to work instead of coming
out black!
2024-04-12 07:14:34 -07:00
410ace106e Launch NeoPass to all! <3 <3 2024-04-12 06:51:20 -07:00
7769016556 Tweak NeoPass beta copy and widen the net again
Not getting a lot of takers, I think it was wise to start small just in
case, but there doesn't seem to be a floodgate problem, so let's remove
the limitations and increase the ask! (But still not a full launch yet,
because I want to funnel people through the feedback process first.)
2024-04-11 11:40:16 -07:00
99277aecdd Update NeoPass beta test copy & widen the net a bit 2024-04-11 09:49:00 -07:00
2673baa7ff Tweak login page styles some more: page title & Remember Me 2024-04-11 09:48:29 -07:00
8de5591719 Split login page into two columns: password login and NeoPass login
I also wrote up some explainer text for the NeoPass option, too!
2024-04-11 09:12:59 -07:00
724f22e602 Very basic login form polish 2024-04-11 08:54:42 -07:00
2cc6cee542 Style "Log in with NeoPass" button to better match Neopets
Got the icon and background style from Neopets.com! I didn't quite copy
the whole button style, both because getting it to play nice with our
existing styles didn't *immediately* work, but also because I think
this works out as a really good compromise between our two styles
anyway!
2024-04-11 08:47:19 -07:00
eb8e5d6df5 Show the NeoPass testing form link to 25% of users on the homepage
It's happening! 
2024-04-11 07:29:01 -07:00
644b181ed0 Use Neopets username as base name for new NeoPass accounts, if possible
Yay, we got the API endpoint for this! The `linkage` scope is the key.

Rather than pulling back the specific fallback behavior we had wrote
for usernames before, which was slightly different and involved
appending `neopass` in there too (e.g. `matchu-neopass-1234`), I
figured let's just use a lot of the same logic, and just use the
preferred name as the base name. (I figure the `neopass` suffix isn't
that useful anyway, `matchu-1234` kinda looks better tbh! And it's all
fallback stuff that I expect serious users to replace, anyway.)
2024-04-09 07:48:13 -07:00
9ed34fa042 Add User-Agent header to our OwlsValueGuide requests
Note: I validated this was working by temporarily changing the URI to
`https://echo.free.beeceptor.com`, which echoes the headers back, then
called `OwlsValueGuide.load_itemdata` directly.
2024-04-09 06:59:44 -07:00
eb5f2a020c Add User-Agent header to our NeopetsMediaArchive requests
Note: I validated this was working by temporarily changing the URI to
`https://echo.free.beeceptor.com`, which echoes the headers back, then
called `NeopetsMediaArchive.load_file_from_origin` directly.
2024-04-09 06:58:03 -07:00
d50672fd73 Add User-Agent header to our AMFPHP requests
Oh right, I never did catch this when setting up User-Agent in the app!

(I noticed this because I'm making a new request now, and went to look
how we set it in previous stuff, and was like. Oh. We don't anywhere
right now. Interesting LOL)
2024-04-09 06:55:41 -07:00
58d86cf3ac Prevent user from removing all their login methods
Oh right, if you can remove your email, there's a way to fully lock out
your account:

1. Create account via NeoPass, so no password is set.
2. Ensure you have an email saved, then disconnect NeoPass.
3. Remove the email.
4. Now you have no NeoPass, no email, and no password!

In this change, we add a validation that requires an account to always
have at least one login method. This works well for the case described
above, and also helps offer server-side validation to the "can't
disconnect NeoPass until you have an email and password" stuff that
previously was only enforced by disabling the button.

That is, the following procedure could also lock you out before,
whereas now it raises the "Whoops, there was an error disconnecting
your NeoPass from your account, sorry." message:

1. Create account via NeoPass, so no password is set.
2. Ensure you have an email saved, so "Disconnect" button is enabled.
3. Open a new browser tab, and remove the email.
4. In the original browser tab, click "Disconnect".
2024-04-09 06:40:56 -07:00
9384fd2aa7 Add additional cookie method to view hidden NeoPass features
This is gonna help me in development, to stop having to add stuff to
the URL all the time!! I also considered just always making it
available in development, but I wanted to match production behavior to
help us ensure the hiding behavior is working, to avoid leaking NeoPass
without realizing.
2024-04-09 06:36:44 -07:00
95c1a4f391 Fix bugs in Settings page when changes to the model are incomplete
Ahh okay tricky lil thing: if you show the settings page with a partial
change to `AuthUser` that didn't get saved, it can throw off the state
of some stuff. For example, if you don't have a password yet, then
enter a new password but leave the confirmation box blank, then you'll
correctly see "Password confirmation can't be blank", but you'll *also*
then be prompted for your "Current password", even though you don't
have one yet, because `@auth_user.uses_password?` is true now.

In this change, we extend the Settings form to use two copies of the
`AuthUser`. One is the copy with changes on it, and the other is the
"persisted" copy, which we check for parts of the UI that care about
what's actually saved, vs form state.
2024-04-09 06:34:06 -07:00
f450937952 Oops, fix error when saving user settings with no password set
Ah okay, if you leave the password field blank but don't have one set,
our simple `update` method gets annoyed that you left it blank.

In this change, we simplify the model API by just overriding
`update_with_password` with our own special behavior for the
no-password case.
2024-04-09 06:20:13 -07:00
d10c11e261 Oops, fix tracking neopass_email on account creation.
My bad!
2024-04-09 05:45:39 -07:00
0a046ed9c1 Oh right, hide NeoPass on settings page unless you set the magic param!
Simplified this a bit into a helper. It's kinda odd to me, but
convenient for this moment, that Rails allows views to read `params`! I
guess it's for escape hatches exactly like this! lol
2024-04-08 05:34:47 -07:00
5cc219c795 Connect a NeoPass to an existing account
including validation logic to make sure it's not already connected to
another one!

The `intent` param on the NeoPass form is part of the key! Thanks
OmniAuth for making it easy to pass that data through!
2024-04-08 05:33:58 -07:00
09bccd41da Oops, stop saying "Welcome back" for new NeoPass users!
Ahh I see, if you do a no-op update, it still clears the
`previously_new_record?` state, so our NeoPass controller thinks this
account already existed. Instead, let's only do this update if it's an
account that already exists, instead of depending on the no-op-iness!
2024-04-08 05:00:27 -07:00
889c454c65 Oops, fix a redirect URL I missed when ejecting from Devise controller 2024-04-08 04:32:34 -07:00
f6d3992045 Don't require current_password for settings if user doesn't have one 2024-04-08 04:13:07 -07:00
0f5bb2a861 Oops, stay signed in when changing password 2024-04-08 04:12:46 -07:00
ae2b62956a Eject AuthUsersController from the default Devise controller
I'm getting ready to add handling for "what if you don't *have* a
current password*??", so it seems like the right way to do that is to
just eject the controller and start customizing!
2024-04-08 04:02:54 -07:00
3e92d89765 Fix error when multiple accounts have a blank email address 2024-04-08 03:46:41 -07:00
ed89380152 Oops, allow NeoPass to be disconnected if you have no email address
That is, you're required to add a password *or* an email before
disconnecting your NeoPass, but idk, I think it's rude to demand an
email from someone for the sake of *disconnection*. Email is no longer
required for accounts that already exist!
2024-04-07 08:42:41 -07:00
b5e203c0e5 Oops, fix settings page styles when validation fails
Ahh right, when I fixed this for Turbo, I forgot this page can also
render in the `update` action when it fails!
2024-04-07 08:32:38 -07:00
54a052848a Disable disconnecting NeoPass if no password/email is set
Just as a precautionary thing! Seems polite.
2024-04-07 08:27:02 -07:00
b827727102 Rename AuthUser#neopass? -> AuthUser#uses_neopass?
This is more consistent with the `uses_omniauth?` we already have, and
it also will help for the next change, where I want a `uses_password?`
method (and using the name `password?` breaks some of Devise's
validation code).
2024-04-07 08:12:38 -07:00
89fc99c918 Oops, fix bug for authorizing the NeoPass disconnect endpoint
Ahh right, in development `User` and `AuthUser` will have the same ID,
but that got messed up early on for us in production DTI 😅

Here, we switch the form to reference the `User` instead of the
`AuthUser` (to get the ID right), then we also change how we compare
the IDs, because `User#to_param` appends extra text onto the ID after
the number!
2024-04-07 08:11:22 -07:00
66978bf5a0 Oops, fix Settings page styles spreading to other pages via Turbo
Oh right, I made this mistake before too, lol! Once stylesheets are
added, they don't go away!
2024-04-07 08:04:32 -07:00
88a2688ac8 Add form to disconnect NeoPass
Can't connect it back yet! But you can disconnect it! :3
2024-04-07 07:52:23 -07:00
21b967f83d Add some NeoPass info to the Settings page, if you have one
No buttons to change it or anything, or to link if you don't! Just a
basic display and explanation!
2024-04-07 07:17:33 -07:00
d5c3bc087e Track neopass_email when logging in with NeoPass
Gonna use this in the Settings UI to communicate what NeoPass you're
connected to!
2024-04-07 07:17:07 -07:00
82aea20679 Redesign user settings form
Motivation is that I wanna add NeoPass stuff to here! But also like,
it's looked bad for a long time, let's clean it up!! (I just used the
Devise default without any styling at all lol)
2024-04-07 06:43:29 -07:00
8e269df3c1 Oh wow, don't use the images.neopets.com asset proxy anymore either!
Huh, I was writing up an API inventory doc to send to TNT, and was
gonna explain why we proxy these assets… but turns out we don't need to
anymore! Nice!

This is a bit fragile if they ever change their headers, so I'll
mention that in the doc, but for now, yeah sure let's save the planet
some computational effort!
2024-04-06 03:38:23 -07:00
bb90f92a06 Don't use the pets.neopets.com asset proxy anymore
Ah right, now that HTTPS works, we can skip this!
2024-04-06 03:25:06 -07:00
bd4b67316c Refactor image hash loading to use PetService.getPet, not CPN redirs
Previously, the way we loaded the image hash for a given pet was to
navigate to `https://pets.neopets.com/cpn/<pet_name>/1/1.png`, but
*not* follow the redirect, and extract the image hash from the URL
where it redirected us to.

In this change, we refactor to use the AMFPHP RPC `PetService.getPet`
instead. I don't think it had this data last time I looked at it, but
now it does! Much prefer to use an actual RPC than our weird hacky
thing!

(We might also be able to use this call for other stuff, like
auto-labeling gender & mood for pet states, maybe?? That's in this data
too! We used to load petlookups for this, long long ago, before the
petlookup captchas got added.)
2024-04-06 02:56:40 -07:00
1d3aac436b Fix detecting "pet not found" case
Oh huh, now instead of returning an AMF error message, the service
returns a blank pet object if the pet doesn't exist. Okay!
2024-04-06 02:49:08 -07:00
ebc01518bd Remove unused Pet::WARDROBE_PATH constant
Huh, weird! Goodbye!
2024-04-06 02:38:20 -07:00
848e71f16d Remove unused Pet.from_viewer_data constructor
I guess this was like, we had some call site that was handling loading
the viewer data itself, and didn't want to have to reload it?

But whatever, not used now, let's simplify! We can rebuild this easily
if we need it again.
2024-04-06 02:33:28 -07:00
f0ac2adc78 Remove unused options when loading pets
Locale is the big one that's not really relevant anymore (I don't want
to be loading non-English item names anymore, now that we've simplified
to only support English like TNT has!), but there was also `item_scope`
and stuff.

The timeout option is technically not used in any call sites, but I
think that one's useful to leave around; timeout stuff is important,
and I don't want to rewrite it sometime if we need it again!
2024-04-06 02:31:24 -07:00
57dcc88b27 Refactor pet image hash loading into the Pet model, not PetType
Just a small thing, I guess when I was a kid I did a weird thing where
I attached `origin_pet` to `PetType`, then upon saving `PetType` I
loaded the image hash for the pet to save as the pet type's new image
hash.

I guess this does have the nice property of not bothering to load that
stuff until we need it? But whatever, I'm moving this into `Pet` both
to simplify the relationship between the models, and to prepare for
another potential refactor: using `PetService.getPet` for this instead!
2024-04-06 02:25:22 -07:00
3419f8b8d1 Tweak NeoPass login success messages, to focus less on random username
Until we have more figured out about the username situation here, let's
not greet the user by the name we *generated* for them.
2024-04-01 06:00:49 -07:00
6618651fcb Use completely random NeoPass usernames for now
Ahh, I had assumed the `uid` provided by NeoPass would be the user's
Neopets username, but in hindsight that was never gonna work out since
NeoPass doesn't think of things in terms of usernames at all!

For now, we create 100% random NeoPass usernames, of the form
"neopass-shoyru-5812" or similar. This will be an important fallback
anyway, because it's possible to have a NeoPass with *no* Neopets.com
account attached.

But hopefully we'll be able to work with TNT to request the user's main
Neopets account's username somehow, to use that as the default when
possible!
2024-04-01 05:57:06 -07:00
b03d9b264a Increase maximum username length to 30
I'm writing some code for default NeoPass usernames, and they can get
kinda long, so I want to clear some extra space for them!
2024-04-01 05:53:38 -07:00
fcc17d3dcf Whoops, fix some style regressions for the React app!
Ah beans, I didn't notice when doing my Turbo fixes in
40804c1543, that I had accidentally
prevented Chakra from applying some of its usual global styles! This
caused some minor visual regressions in various parts of the app, e.g.,
the default border color for the search field in the wardrobe app
became way darker.

Here, instead of copy-pasting the styles and missing some parts, we
scope the global styles a bit more carefully: we first use
`extendTheme` with the same code as Impress 2020 to get a good
`globalStyles` function that includes Chakra's defaults, *then* delete
the key from the theme.

Then, in `ScopedCSSReset`, we use code similar to Chakra's own global
style application code: call the `globalStyles` function with the
current theme and color mode, use Chakra's `css` function to convert
values like `green.800` to CSS values, prepend our scoping rule onto
the selectors, and drop it into our Emotion CSS.

Tbh I was worried because when I first noticed this issue while on my
trip, I saw the black item search box border, and was like "ah dang,
did I destroy all the color in the app by breaking the part where
Chakra defines its CSS color variables??" And no, that's not actually
what happened, a lot of the app still had its colors!

So this was less pressing than I had thought, but still good to get
fixed!
2024-03-31 01:20:45 -07:00
f4133f8283 Add some cheesy formatting to the placeholder NeoPass UI
Just to make it fun and cute! I'm doing some other stuff for demo video
purposes, but this is the only one I'm committing :p
2024-03-14 19:47:19 -07:00
7f4c34ff6a Oops, stop requiring a new password whenever AuthUser is changed
Ah right, I went and checked the Devise source code, and the default
implementation for `password_required?` is a bit trickier than I
expected:

```ruby
def password_required?
  !persisted? || !password.nil? || !password_confirmation.nil?
end
```

Looks like `super` does a good enough job here, though! (I'm actually
kinda surprised, I wasn't sure how Ruby's `super` rules worked, and
this isn't a subclass thing—or maybe it is, maybe the `devise` method
adds a mixin? Idk! But it does what I expect, so, great!)

So now, we require the password if 1) Devise doesn't see a UI reason
not to, *and* 2) the user isn't using OmniAuth (i.e. NeoPass).

This had caused a bug where it was impossible to use the Settings page
*without* changing your password! (The form says it's okay to leave it
blank, which stopped being true! But now it's fixed!)
2024-03-14 19:20:33 -07:00
3eeb5d1065 Actually create user from NeoPass authentication! <3 <3
Whew, exciting! Still done nothing against the live NeoPass server, but
we've got this fully working with the development server, it seems!
Wowie!!

This is all still hidden behind secret flags, so it's fine to deploy
live. (And it's not actually a problem if someone gets past to the
endpoints behind it, because we haven't actually set up real
credentials for our NeoPass client yet, so authentication will fail!)

Okay time to lie down lol.
2024-03-14 19:11:06 -07:00
31a11a04fa Read and customize the username reported by neopass-server
Okay, `sub` seems to be a pretty standard place for user identifiers.
Let's start with that assumption! I override the `oauth2-mock-server`'s
default of `johndoe` with `theneopetsteam`, just to be cute :3
2024-03-14 18:19:45 -07:00
f483722af4 NeoPass strategy interacts with dev NeoPass server, which is still WIP
In this change, we wire up a new NeoPass OAuth2 strategy for OmniAuth,
and hook up the "Log in with NeoPass" button to use it!

The authentication currently fails with `invalid_credentials`, and
shows the `owo` response we hardcoded into the NeoPass server's token
response. We need to finally follow up on the little `TODO` written in
there!
2024-03-14 16:13:31 -07:00
77057fe6a2 Add hidden "Log in with NeoPass" button, to placeholder login strategy
If you pass `?neopass=1` (or a secret value in production), you can see
the "Log in with NeoPass" button, which currently takes you to
OmniAuth's "developer" login page, where you can specify a name and
email and be redirected back. (All placeholder UI!)

We're gonna strip the whole developer strategy out pretty fast and
replace it with one that uses our NeoPass test server. This is just me
checking my understanding of the wiring!
2024-03-14 15:34:24 -07:00
08b1b9e83b Add OmniAuth plugin to AuthUser
This is setting us up for NeoPass, but first we're just gonna try stuff
with the "developer" strategy that's built in for testing, rather than
using the NeoPass dev server!
2024-03-14 15:06:13 -07:00
3bf3eaac8a Fix scoping on CSS for donate page
Oh right, all these cute overrides should be scoped to the page!

I guess we skipped this because we had pulled this out into a
separate stylesheet. Curiously learning more about how Turbo handles
this kind of thing, like that it doesn't *unload* stylesheets that
*leave* the page when you navigate!
2024-03-13 22:13:16 -07:00
c3eab22b4e Downgrade jQuery on homepage to be the same version as everywhere else
I noticed an issue where Turbo-loading between the Your Items page and
the homepage would clobber each other's copy of jQuery, breaking things
sometimes. e.g. go to Your Items, then go to home, then go to Your
Items, and the page's JS fails because `$.fn.live` isn't defined.

I briefly tested the homepage and it didn't seem to actually depend on
any features from the later version of jQuery? At least not that I
noticed! So I'll just downgrade for consistency. (I also tried
upgrading the Your Items page, but there's too much usage of
`$.fn.live`, which is replaced with a notably different syntax in
jQuery 2.0+.)
2024-03-13 21:38:45 -07:00
c011e99819 Fix various JS Turbo issues
First one, Turbo reasonably yelled at us in the JS console that we
should put its script tag in the `head` rather than the `body`, because
it re-executes scripts in the `body` and we don't want to spin up Turbo
multiple times!

I also removed some scripts that aren't relevant anymore, fixed a bug
in `outfits/new.js` where failing to load a donation pet would cause
the preview thing to not work when you type (I think this might've
already been an issue?), reworked `item_header.js` to just run once in
the `head`, and split scripts into `:javascripts` (run once in `head`)
vs `:javascripts_body` (run every page load in `body`).
2024-03-13 21:26:22 -07:00
40804c1543 Fix the Chakra CSS reset applying to too many things on item page
Finally getting around to this because, with Turbo in play, it applies
to subsequent *pages* too, oops! Previously we at least had the blast
radius of this known issue constrained to the item page itself lol :p
2024-03-13 20:57:30 -07:00
d118d185e2 Add more NeoPass details to about page
Got some questions in Discord about account unlinking, and seeing
people look ahead to other potential integrations. Want to clarify that
unlinking will work here (barring any surprises!), and that there's no
data sharing _just_ yet!
2024-03-13 17:55:23 -07:00
75418339da Add DTI 2020 link to item pages
Someone requested this in Discord, and I figured why not! I'm still
planning to move stuff away from Impress 2020 over time, I just figure
may as well have them more linked while this is still The Reality
2024-03-13 17:46:45 -07:00
9295ae75ad Add the full ".html.haml" extension to "_item_header.haml"
This doesn't really matter, I just didn't realize the `.html` part was
optional, and I guess I omitted it here without realizing? But let's
add it for consistency.
2024-03-13 17:35:25 -07:00
01f9065dbd Fix incorrect closet list deletion prompt message
It's no longer true that we transfer the items to the default list; we
just delete them now!
2024-03-13 13:59:27 -07:00
5631b02157 Fix confirmation prompts for various actions
These were depending on the `rails-ujs` scripts we haven't had in here
for a while! Now, they use the new equivalent Turbo attributes.
2024-03-13 13:56:10 -07:00
9fe44e3f91 Hack to speed up loading the homepage
The modeling code is slow! I think in production it's being cached, and
tbh I though I had development mode caching turned on over here, but
it's quite evidently _not_ doing it if so, so. Okay! Skip for now.
2024-03-13 13:51:28 -07:00
684dcb53ba Add Turbo to speed up the app, and set up for missing UJS features
Oh right, we don't have Rails UJS going on anymore, which is what
handled the confirmation prompts for deleting lists. Turbo is the more
standard modern solution to that, and should speed up certain
pageloads, so let's do it!

Here I install the `turbo-rails` gem, then run `rails turbo:install` to
install the `@hotwired/turbo-rails` npm package. Then I move
`application.js` that's run all on pages but the outfit editor into our
section of JS that gets run through the bundler, and add Turbo to it.

I had to fix a couple tricky things:

1. The outfit editor page doesn't play nice with being swapped into the
   document, so I make it require a full page reload instead.
2. Prefetching the Sign In link can cause the wrong `return_to` address
   to be written to the `session`. (It's a GET request that does, ever
   so slightly, take its own actions, oops!) As a simple hacky answer,
   we disallow prefetching on that link.

Haven't fixed up the UJS stuff for confirm prompts to use Turbo yet,
that's next!
2024-03-13 13:43:48 -07:00
b39542a2ba Merge branch 'about-neopass' 2024-03-13 12:22:32 -07:00
6a347bd733 Add "Posted" date to NeoPass announcement 2024-03-13 12:22:15 -07:00
b388486676 Add NeoPass announcement banner to homepage 2024-03-13 12:20:38 -07:00
3f172b91c5 Oops, fix redirect to item thumbnail
This `.gif` format is used in the items list "export to petpage"
feature, as the image URL for items whose URLs are known to contain
blocked words that prevent them from being used in petpages.

But when doing some Rails upgrade long ago, we didn't notice the new
security feature that blocks redirects to other sites without a special
flag being set. It was triggering 500 errors, oops.

Now, we set the flag!
2024-03-12 18:45:05 -07:00
3bf07b02da A few more NeoPass about page copy edits 2024-03-12 18:41:58 -07:00
4bff5b7943 Oops, add dimensions to NeoPass header image
Always forget about this! Lol
2024-03-12 18:41:44 -07:00
ba859ce747 Oops, fix neopass-header.png image reference
Huh, omitting the filetype is legal in development, but failed in
production. Weird!
2024-03-12 18:34:40 -07:00
640e0423a7 Copy edits, mostly bolding sections of the NeoPass about page 2024-03-12 18:21:23 -07:00
0e7457980f Add NeoPass header image 2024-03-12 18:20:57 -07:00
022286a746 Add first draft of /about/neopass page 2024-03-12 17:58:44 -07:00
2cfcfaf69d Rename StaticController to AboutController
This is where `/about` pages will go now!
2024-03-12 17:12:43 -07:00
9aef987f95 Move partials in views/static to views/application
I think this is the more canonical place for stuff like this these days!
It's nice to be able to just say the short name when calling `render`.

Here's the answer I looked up about it: https://stackoverflow.com/a/9892081/107415

My immediate motivation is that I'm looking at creating more About
pages, and thinking about where to put them; I think maybe we trash the
`StaticController`, move these partials out to here, and move terms
into a new `AboutController`?
2024-03-10 18:48:25 -07:00
cf6921329d Oops, choose the *first* PNG from the manifest, to avoid reference art
When we moved more logic into the main app, we made some assumptions
about manifest art that were different than Impress 2020's, in hopes
that they would be More Correct for potential future edge cases.

Turns out, they were actually *less* correct for *current* edge cases!
Chips linked us to a few examples, including this Reddit post:

https://www.reddit.com/r/neopets/comments/1b8fd72/i_dont_think_thats_the_correct_image/

Fixed now!
2024-03-07 14:16:05 -08:00
88c98f2023 Update GitHub links to point to our self-hosted OpenNeo Code 2024-02-29 11:24:21 -08:00
9156fa7162 Bold the Terms of Use link when it's been changed recently 2024-02-29 11:22:12 -08:00
0316544e32 Update Terms of Use
Mostly pulled from Impress 2020, but with some copy edits, and AI
clauses added for good measure.
2024-02-29 11:21:53 -08:00
b7a4bb988b Remove unused static/terms stylesheet
This gets put into the application stylesheet because of our silly way
of doing stylesheets. Let's have it begone!
2024-02-29 10:53:06 -08:00
bc8d265672 Add handlers for requests that were stopped during the reboot process
According to our GlitchTip error tracker, every time we deploy, a
couple instances of `Async::Stop` and `Async::Container::Terminate`
come in, presumably because:

1. systemd sends a STOP signal to the `falcon host` process.
2. `falcon host` gives the in-progress requests some time to finish up
3. Sometimes some requests take too long, and so something happens.
   (either a timer in Falcon or a KILL signal from systemd, not sure!)
   that leads the ongoing requests to finally be terminated by raising
   an `Async::Stop` or `Async::Container::Terminate`. (I'm not sure
   when each happens, and maybe they happen at different points in the
   process? Maybe one happens for the actual long-running ones, vs the
   other happens if more requests come in during the meantime but get
   caught in the spin-down process?)
4. Rails bubbles up the errors, our Sentry library notices them and
   sends them to GlitchTip, the user presumably receives the generic
   500 error, and the app can finally close down gracefully.

It's hard for me to validate that this is *exactly* what's happening
here or that my mitigation makes sense, but my logic here is basically,
if these exceptions are bubbling up as "uncaught exceptions" and
spamming up our error log, then the best solution would be to catch
them!

So in this change, we add an error handler for these two error classes,
which hopefully will 1) give users a better experience when this
happens, and 2) no longer send these errors to our logging 🤞️

That strange phenomenon where the best way to get a noisy bug out of
your logs is to fix it lmao
2024-02-28 13:50:13 -08:00
522287ed53 Fix MissingAttributeError in ClosetHanger#merge_quantities
Oh rough, when moving an item list entry from one list to another, our
logic to merge their quantities if it's already in that list was just
fully crashing!

That is, moves without anything to merge were working, but moves that
required a merge were raising Internal Server Error 500, because the
`list_id` attribute wasn't present.

I'm not sure why this ever worked, I'm assuming using `list_id` in the
`where` condition would include it in the `select` implicitly in a
previous version of Rails? Or maybe Rails used to have fallback
behavior to run a second query, instead of raising
`MissingAttributeError` like it does now?

Well, in any case, this seems to fix it! Whew!
2024-02-28 13:30:55 -08:00
d8b3f613e3 Fix AccessDenied error handler
I don't think people see this very often visually, but it's showing up
in our error logging! The Rails API changed here long ago and we didn't
notice: to render public files, we should use the `file` argument
instead of `template`.
2024-02-28 13:20:41 -08:00
0ed4e8f216 Add "Baby Body Paint" warning to Known Glitches badge in-app, too
I previously added a warning to the item page, and thought about doing
one here but was sicky and misjudged the complexity and forgot you
don't need to hook into the `knownGlitches` API field to do it! Easy
peasy for a hacky little bug message!
2024-02-27 19:22:08 -08:00
6a0afb330b Add warning for "Baby Body Paint" bugs
I *think* what I'm observing is that:

1. The zone restrictions are different between these items.
2. The zone restrictions *change* when reloading the page sometimes. (I
   assume from remodeling?)
3. The items look very buggy on many pets, because many appearances
   seem to expect different zone restrictions than the item actually
   has.

I think what this means is:

1. TNT has finally unbound restricted zones from the item level, and
   allowed different appearances to have different restrictions. Neat!
2. The API still serves it the same way, as a field on the item.

So I think this means we need to update our schema to reflect the fact
that an item's `zones_restrict` field isn't *really* a property of the
item; it's a property of the combination of the item and the current
body ID.

My gut take here is that maybe this means it's time for the Large
Refactor that I've kinda been interested in for a while, but been
avoiding because of Impress 2020 compatibility issues: instead of a
`body_id` field on assets, and having them directly belong to items,
make an `ItemAppearance` record (closer to how 2020's GQL API modeled
it, I was looking ahead to this possibility!) that's keyed on item and
body ID, and assets belong to *that*.

Then, we could move the zones restriction field onto the
`ItemAppearance` record instead. And then it doesn't really matter to
us how TNT models it internally; whatever we saw is what we use.
(Again, I looked ahead to this in the 2020 app, and tried to use the
`restrictedZones` field on `ItemAppearance` when possible—even though
it secretly just reads directly from the `Item`!)

…but that's a pretty big departure from how things are modeled now, and
isn't something we can just throw together—especially coordinating it
across both apps. I was getting close to being able to shut off 2020
from a *front-facing* perspective (but still keeping a lot of the GQL
endpoints open for the wardrobe-2020 frontend), but I don't think we're
very close to being able to try to target turning off 2020's *backend*
as a prereq to this; or at least, if we do, we should expect that to
take a while. (Counting now, there's still 9 GQL queries—not as many as
I expected tbh, but still quite a few.)

So idk how to sequence this! But for now, let's put out a warning, and
start setting expectations.
2024-02-27 18:16:23 -08:00
4f069a5742 Remove the GQL-based useSearchResults, everyone is on it now!
The main *intended* user-facing effect of this is that "Items you own"
and "Items you want" filters should work in wardrobe-2020 now!

It is also possible that I messed something up and that this might
break unrelated searches somehow! We'll find out!! 😅
2024-02-27 16:49:52 -08:00
ece7a02902 Remove our testing-escape-hatch for item search from the console
Did this before we had the ability to trigger searches from the app
itself, to allow me to open up the browser JS console and call this
function directly. Now we can just do it in app, goodbye!
2024-02-27 16:25:17 -08:00
87782767f8 Filter search in wardrobe-2020 by alt styles!
Yay, we finally added it, the part where we include the appearance data
for the items based on both the species/color and the alt style! Now,
switching to Faerie Acara correctly filters the search only to items
that would fit (I think literally just only body_id=0 items right now,
but we're not banking on that!)
2024-02-27 16:11:06 -08:00
421f2ce39f Use fits:nostalgic-faerie-draik filter format when we can
This only *really* shows up right now in the case where you construct
an Advanced Search form query (which only the wardrobe-2020 app does
now, and in limited form), and we return the query back (which only
gets used by the HTML view for item search, which doesn't have any way
to build one of these requests against it).

This is because, if you just type in `fits:alt-style-87305`, we always
keep your search string the same when outputting it back to you, to
avoid the weirdness of canonicalizing it and changing it up on you in
surprising ways!

But idk, this is just looking forward a bit, and keeping the system's
semantics in place. I hope someday we can bring robust text filter
and Advanced Search stuff back into the main app again, maybe!
2024-02-27 15:51:27 -08:00
18c7a34b8f Update series_name for alt styles to be null, with a fallback string
I considered this at first, but decided to keep it simple until it
turned out to matter. Oops, it already matters, lol!

I want the item search code to be able to easily tell if the series
name is real or a placeholder, so we can decide whether to build the
filter text in `fits:$series-$color-$species` form or
`fits:alt-style-$id` form.

So in this change, we keep it that `AltStyle#series_name` returns the
placeholder string if none is set, but callers can explicitly ask
whether it's a real series name or not. Will use this in our next
change!
2024-02-27 15:48:28 -08:00
9243193bc8 Add support for fits:alt-style-87305 item searches
Easy peasy!
2024-02-27 15:36:45 -08:00
d983a20989 Add support for fits:nostalgic-faerie-draik item searches
Nice and easy now that we have `series_name` in the database!

I didn't add the `fits:alt-style-12345` case yet though!
2024-02-27 15:33:08 -08:00
9f74e6020e Add series_name database field to alt styles
Previously we did this hackily by comparing the ID to a hardcoded list
of IDs, but I think putting this in the database is clearer and more
robust, and it should also help with our upcoming item search stuff
that will filter by it!
2024-02-27 15:28:05 -08:00
cd786ffcb1 Oops, I broke user filters in my previous refactor!
Right, `user` is an important argument that I missed! 😅
2024-02-27 15:08:15 -08:00
76d741091c Extract "raise_search_error" method in item search query parsing
Just to make all this a bit more wieldy, and not repeat the same prefix
all the time!
2024-02-27 15:03:18 -08:00
61b1a1aed1 Improve parsing fits:blue-acara filter
Previously, passing in `fits:blue` would cause a crash, because
`species_name` part of the split would be `nil`, oops!

In this change, we use a regex for more explicitness about the pattern
we're trying to match. We'll also add more cases next! (You'll note the
error message mentions `fits:nostalgic-faerie-draik`, which isn't
actually possible yet, but will be!)
2024-02-27 14:56:36 -08:00
1860f5b6be Fix showing the query on the item search error page
Previously, the query wouldn't fill into the search box or page title
if e.g. parsing had failed. Now it does!

I'm not sure why the rescue strategy we previously had here doesn't
work anymore (I'm sure it must've in the past sometime?), but this is
simpler anyway, let's go!
2024-02-27 14:47:57 -08:00
bdefeb53d6 Remove weird unused begin/end block in ItemsController 2024-02-27 14:47:02 -08:00
19ebf4d78a Extract item search filter parsing into helper methods
I think this is a bit clearer and lets us clean up some of the syntax a
bit (don't need to always say `filters <<`), and also it will let us
use `return`, which I'm interested in for my next change!
2024-02-27 14:43:42 -08:00
3781c9810a Item search can filter by fitting alt styles (but missing many details!)
A query like this works for finding items containing "hat" that fit
alt style #87296 (the Faerie Acara):

http://localhost:3000/items?q%5B0%5D%5Bkey%5D=name&q%5B0%5D%5Bvalue%5D=hat&q%5B1%5D%5Bkey%5D=fits&q%5B1%5D%5Bvalue%5D%5Bspecies_id%5D=1&q%5B1%5D%5Bvalue%5D%5Bcolor_id%5D=8&q%5B1%5D%5Bvalue%5D%5Balt_style_id%5D=87296

But there's two main missing pieces still:
1. You can't do a text-filter version of this—in fact, clicking Search
   immediately on the page this loads will return an error!
2. We haven't extended this to the `with_appearances_for` parameter,
   so we add a `NotImplementedError` to that bit for now too.

I'm also thinking that the text filter should ideally be like,
`fits:nostalgic-faerie-acara` if we can pull it off; and then fall back
to the plainer `fits:alt-style-87296` if e.g. we don't know the set
it's from yet.
2024-02-27 14:32:54 -08:00
183cb40e74 Oops, don't return body_id=0 items for "-fits:blue-acara"
Right, fitting isn't just body_id = this one, it's also body_id=0!

Anyway, doing this query on its own is still deathly slow, I wonder if
the idea I had about left joins (back when I was still working in a
Rails version that didn't support it lol) could help! Might poke at
that a smidge.
2024-02-27 14:07:20 -08:00
671a79d158 Refactor fits and not_fits in Item::Search::Query
Just restructuring a bit in anticipation of changes we're gonna make
for alt style support in here!
2024-02-27 14:05:37 -08:00
f3e10dea7f Oops, fix missing field in item search results Apollo cache!
Oh right, `imageUrl` is the name of the field relative to what the app
expects, but under the hood `useOutfitAppearance` actually makes that
an alias for `imageUrlV2(idealSize: SIZE_600)`.

So we need to cache it as the same field with the same params, rather
than as just plain `imageUrl`!

This fixes the bug where wearing an item from search would require a
network round-trip and visually remove all items in the meantime.

(Also, none of this issue was visible to most users, because item
search is still feature-flagged onto the old GQL one for most people!)
2024-02-27 12:43:28 -08:00
66c1e14dd0 Add item search results to Apollo cache, use in finding item conflicts
This makes clicking on search results in the new mode actually work! It
correctly adds it to the outfit, and removes other items.

The thing that's behaving strangely is that, when you add the item, we
visually remove all items until we can finish a fresh network request
for what they should all look like. This probably means that the cache
lookup for `useOutfitAppearance` is not as satisfied with what we cache
here as `findItemConflicts` is? Something to investigate!
2024-02-27 12:19:07 -08:00
752bee3c39 Use MajorErrorMessage for search result errors
It'd be nice to customize the message a bit, but this should be rare
and I'd prefer the simplicity of just going with the default text.

I ran into this when I made a mistake in how I process the return value
of search results, so React Query caught and raised the error via
React, as intended! And I was annoyed that it wasn't logged anywhere,
so that's my motivation for this change—but also, the old message is
pretty meh and has some layout problems anyway.
2024-02-27 12:03:23 -08:00
2e5b1c7350 Remove unused Item.per_page attribute
I feel like this was part of `will_paginate` back before the Rails
community had itself figured out about what belongs in a model?

But yeah, a default per-page value for search results does not belong
here. And I don't think anything references it anymore, because we pass
`per_page` to the `paginate` call in `ItemsController` explicitly! So,
goodbye!
2024-02-25 16:16:43 -08:00
fb2bdd6ea5 Fix crash when dealing with 404'd manifests
First off, I think our code has converged on a convention of gracefully
returning `nil` for manifest-less situations, so we can do that instead
of raise! And then that lets us just simplify this check to whether
`manifest` is present, instead of `manifest_url`, so we stop crashing
in cases where we get to this point in the code and there's a manifest
URL but not a manifest.
2024-02-25 16:05:43 -08:00
2cac048158 Save manifest load info when preloading them, too
This was a bit tricky! When I initially turned it on, running
`rails swf_assets:manifests:load` would trigger database errors of "oh
no we can't get a connection from the pool!", because too many records
were trying to concurrently save at once.

So now, we give ourselves the ability to say `save_changes: false`, and
then save them all in one batch after! That way, we're still saving by
default in the edge cases where we're downloading and saving a manifest
on the fly, but batching them in cases where we're likely to be dealing
with a lot of them!
2024-02-25 16:02:36 -08:00
cc33ce1d6e Skip loading manifest if we recently failed
This helps speed up some item search result pages a lot in the new API
endpoint I'm building!
2024-02-25 15:46:50 -08:00
a684c915a9 Track when manifest was last loaded, and what status it returned
Now we're *really* duplicating with Impress 2020's system lol, but I
need a way to not keep trying to load manifests that are actually 404,
which are surprisingly plentiful!

This doesn't actually stop us from loading anything yet, it just tracks
the timestamps and the HTTP status! But next I'll add logic to skip
when it was 4xx recently.
2024-02-25 15:35:04 -08:00
067cee2d41 Oops, fix bug reading manifest assets when .svg is not present
Ah right, I make this mistake a lot when doing `group_by` stuff: if
there's no SVG, then `assets_by_ext[:svg]` is `nil`, not `[]`. Oh well!
2024-02-25 15:02:35 -08:00
e5bf6d6ba1 Oops, fix remaining references to locale in item search
This is both unnecessary now, but also caused a bug in the new search
stuff where searching by zone would pass an extra `locale` argument to
a filter that doesn't need it!
2024-02-25 15:00:22 -08:00
61a4dcad02 Oops, "fits:blue-acara" search should return non-body-specific items
Idk when this regressed exactly, but probably people didn't super
notice because I don't think it's a very common thing to type directly
into the Infinite Closet search box! (It used to be crucial to the old
wardrobe app.)

But I'm using it in the wardrobe app again now, so, fixed!
2024-02-25 14:47:37 -08:00
a8cbce0864 Start working on new item search in wardrobe-2020!
For now, I'm doing it with a secret feature flag, since I want to be
committing but it isn't all quite working yet!

Search works right, and the appearance data is getting returned, but I
don't have the Apollo Cache integrations yet, which we rely on more
than I remembered!

Also, alt styles will crash it for now!
2024-02-25 14:46:27 -08:00
52e81557c2 Update search filters to consider NP and PB mutually exclusive
`is:np` now means "is not NC and is not PB".

Note that it might be good to make NC and PB explicitly mutually
exclusive too? It would complicate queries though, and not matter in
most cases… the Burlap Usul Bow is the only item that we currently
return for `is:pb is:nc`, which is probably because of a rarity issue?
2024-02-25 12:57:04 -08:00
a3dcaa0f0e Add useItemSearch for wardrobe app, but don't use it yet!
Adding new functionality to the item search JSON endpoint, and adding
an adapter layer to match the GQL format!

Hopefully this will be pretty drop-in-able, we'll see!
2024-02-25 12:06:32 -08:00
ab1fade529 Remove unused React dependency on homepage
Oh right, this was for `modeling.jsx`, which is gone now. Bye!
2024-02-25 10:49:00 -08:00
e3d46ea5d0 Remove Alt Styles announcement banner
It's been long enough, and they're linked to from the Styles picker in
the app now!
2024-02-25 10:44:46 -08:00
9ed3c4ff96 Add Alt Styles reference page link to the Alt Styles picker
Clearing the way to be able to delete the announcement banner, which is
currently the only link!

I feel like there's room to redo the site layout to find a place to
more properly link to this from, but I don't have one yet! And this is
enough of a niche reference that I think this is good enough?
2024-02-25 10:44:00 -08:00
258b360ff2 Oops, fix infinite autosaving loop!
A bit of a hack, because the thing triggering it was also a bit of a
hack? I feel like there's something we gotta do with refactoring how
our multiple concepts of state are managed… but in any case! This seems
to keep basic outfit-loading working, while no longer getting us
trapped in autosave loops!

Here's how I reproduced the bug:
1. Open a saved outfit.
2. Set the browser devtools to apply a latency of 5sec to all requests.
3. Add an item to the outfit, and wait for the autosave to start.
4. While it still says "Saving", remove the item again.
5. Watch how, when the first autosave request comes in, the item is
   re-applied to the outfit, then autosave gets stuck looping forever.

The issue was that, when an outfit finishes saving, the change in
outfit data was triggering this effect in `useOutfitState` that was
*meant* to *initialize* local state from the saved outfit, not to keep
them in sync all the time. (In general, when saved outfit data comes
back from the server, we don't want to use it to "fix" local outfit
state in the case of discrepancies, because the most common source of
discrepancy will be the user having made further changes!)

But anyway, one thing I didn't realize is that we *were* depending on
this hacky hook to do more than I thought: it was responsible for
syncing `id` and `appearanceId` to the local state after saving the
outfit. So, I replaced the `rename` action dispatch here with a new
action that explicitly sets all fields the server is responsible for!
2024-02-25 10:37:08 -08:00
56d550e86c Skip loading alt styles on item preview page
Ah yeah, if you're not on the wardrobe page (so we don't need the Alt
Styles UI), and the outfit's `altStyleId` is null (as is the case for
the item preview page), then there's no need to load the alt styles for
that species.

So before this change, going to `/items/123` would include an XHR
request to `/species/<id>/alt-styles.json`, which would not be used for
anything. After this change, that request is no longer sent. Hooray!
2024-02-24 17:23:57 -08:00
7af1a97161 Read known_glitches when loading alt styles SWF assets
I'm not sure why I had marked this as TODO before? Maybe I'm missing
something? But for now I'll just wire it in, I guess!
2024-02-24 16:31:05 -08:00
c5cd1f2f3d Remove SwfAsset#html5_*_url in favor of SwfAsset#urls
The alt styles controller is the one place we use this right now, but
I'm planning to generalize this to loading appearances during item
search, too!

I also add more `only` fields to the alt styles `as_json` call, because
idk it feels like good practice to both 1) say what we need in this
endpoint, rather than rely on default behavior upstream, and 2) to
avoid leaking fields we didn't realize were on there. (And also to
preserve bandwidth, too!)
2024-02-24 16:29:47 -08:00
cd095eefcb Oops, fix crashing bug when loading item appearances endpoint
I missed this because it's only for backgrounds and stuff! But yeah I
added a prefix to the `Body` struct, and forgot to apply it everywhere,
oops!
2024-02-24 16:14:30 -08:00
e0b5382c3f Update SwfAsset#image_url to use all the latest tech
I think there's no call sites for these anymore, so now I can start
repurposing these methods for the new API endpoints I'm planning! :3

Now, `SwfAsset#image_url` approximately matches Impress 2020 logic: use
the thumbnail PNG from the manifest if one exists, or the Impress 2020
converter for canvas movies, or the old AWS copy generated by gnash if
necessary, or return nil.
2024-02-24 16:12:02 -08:00
600cb6b2ea Remove unused /colors/pet_types route
I built this API endpoint in anticipation of a change I never actually
made! I'll just remove it for now, leaning toward cleanuppery over
holding onto something I'm not sure about.
2024-02-24 15:51:40 -08:00
829d960d70 Move SwfAsset#override_body_id to the bottom of the file
This is a console-y method, it's not important enough to be up here!
2024-02-24 15:24:24 -08:00
cf1cdf7e7d Reorder the higher-up lines of SwfAsset
A lot of stuff was mixed together, including methods interrupting the
scopes and relationships, oops! Fixed!
2024-02-24 15:22:14 -08:00
e8737a520e Remove more unused SwfAsset scopes
Wowzers, a lot of cruft in here! I hope I'm not deleting anything
important, but I think my Ctrl-F audits are checking out?
2024-02-24 15:19:28 -08:00
7fee4e6e41 Remove unused SwfAsset.fitting_standard_body_ids and support methods 2024-02-24 15:16:25 -08:00
c25e015b70 Delete some more unused SwfAsset methods 2024-02-24 15:15:21 -08:00
f8cf8165df Remove unused SwfAsset#images method
I think this used to be used in an API endpoint we've now deleted? I'm
just cleaning up call sites because I intend to refactor the `urls`
method and stuff, so I'm removing cruft that would complicate it!

I'm not certain-certain this is unused, but I did a global search for
`\bimages\b` in the codebase, and didn't find anything that looked like
a match to me!
2024-02-24 15:15:21 -08:00
b7f4c5b6ac Remove asset_hosts initializer
It just contains one constant, used in one place. Inlined and deleted!
2024-02-24 15:05:37 -08:00
6a4f2b91c1 Fix inconsistent indentation in pet_types_controller.rb
My editor is making these more obvious, I'm fixing them when I see them!
2024-02-24 15:00:28 -08:00
992954ce89 Create swf_assets:manifests:load task to save all manifest files
Doing that sweet, sweet backfill!! It's not exactly *fast*, since
there's about 570k records to work through, but it's pretty good all
things considered! Thanks, surprisingly-reusable async code!
2024-02-23 14:06:49 -08:00
9a3b33ea2f Preload many manifests concurrently for the Alt Styles page
I'm gonna also use this for a task to try to warm up *all* the
manifests in the database! But to start, just a simple one, to prepare
the alt styles page quickly on first run. (This doesn't really matter
in production now that I've already visited the page once, but it helps
when resetting things in dev, and I think more it's about establishing
the pattern!)
2024-02-23 13:45:12 -08:00
f6cece9a59 Fix inconsistent indentation in swf_assets.rake
My editor now flags this stuff better, thank you editor!
2024-02-23 13:12:21 -08:00
2cc46703b9 Create NeopetsMediaArchive, read the actual manifests for Alt Styles
The Neopets Media Archive is a service that mirrors `images.neopets.com`
over time! Right now we're starting by just loading manifests, and
using them to replace the hacks we used for determining the Alt Style
PNG and SVG URLs; but with time, I want to load *all* customization
media files, to have our own secondary file source that isn't dependent
on Neopets to always be up.

Impress 2020 already caches manifest files, but this strategy is
different in two ways:

1. We're using the filesystem rather than a database column. (That is,
   manifest data is kinda duplicated in the system right now!) This is
   because I intend to go in a more file-y way long-term anyway, to
   load more than just the manifests.
2. Impress 2020 guesses at the manifest URLs by pattern, and reloads
   them on a regular basis. Instead, we use the modeling system: when
   TNT changes the URL of a manifest by appending a new `?v=` query
   string to it, this system will consider it a new URL, and will load
   the new copy accordingly.

Fun fact, I actually have been prototyping some of this stuff in a side
project I'd named `impress-media-server`! It's a little Sinatra app
that indeed *does* save all the files needed for customization, and can
generate lightweight lil preview iframes and images pretty easily. I
had initially been planning this as a separate service, but after
thinking over the arch a bit, I think it'll go smoother to just give
the main app all the same access and awareness—and I wrote it all in
Ruby and plain HTML/JS/CSS, so it should be pretty easy to port over
bit-by-bit!

Anyway, only Alt Styles use this for now, but my motivation is to be
able to use more-correct asset URL logic to be able to finally swap
over wardrobe-2020's item search to impress.openneo.net's item search
API endpoint—which will get "Items You Own" searches working again, and
whittle down one of the last big things Impress 2020 can do that the
main app can't. Let's see how it goes!
2024-02-23 12:02:39 -08:00
3f449310d6 Refactor item search JSON, add appearances
Preparing to finally move wardrobe-2020's item search to use the main
app's API endpoints instead!

One blocker I forgot about here: Impress 2020 has actual support for
knowing an item's true appearance, like by reading the manifest and
stuff, that we haven't really ported over. I feel like maybe I should
pause and work on the changes to manifest-archiving that I'd been
planning anyway? I'll think about it.
2024-02-23 10:44:50 -08:00
1a1615e0ad Oops, fix regression of editor features on item lists page
I changed the type of this tag without realizing the JS references it
by both class and `div`!

I think at the time this was a perf suggestion for jQuery, because the
best way to query by class name was to query by tag first then filter?
It's possible our jQuery still does this, but I don't imagine it's very
relevant today, so I'll just remove that for better guarding against
similar bugs in the future instead.
2024-02-22 15:52:40 -08:00
666394de25 Refactor Impress 2020 config
I've moved the support secret into the encrypted credentials file, and
moved the origin into a top-level custom config value in the
environment files, with different defaults per environment but still
the ability to override it. (I don't use this, but it feels polite to
not actually *demand* that people use port 4000, y'know?)
2024-02-22 13:07:43 -08:00
583f3c712f High-level caching for closet lists
Okay, so I still don't know why rendering is just so slow (though
migrating away from item translations did help!), but I can at least
cache entire closet lists as a basic measure.

That way, the first user to see the latest version of a closet list
will still need just as much time to load it… but *only* the ones that
have changed since last time (rather than always the full page), and
then subsequent users get to reuse it too!

Should help a lot for high-traffic lists, which incidentally are likely
to be the big ones belonging to highly active traders!

One big change we needed to make was to extract the `user-owns` and
`user-wants` classes (which we use for trade matches for *the user
viewing the list right now*) out of the cached HTML, and apply them
after with Javascript instead. I always dislike moving stuff to JS, but
the wins here seem. truly very very good, all things considered!
2024-02-20 18:43:39 -08:00
13b92b30d0 Replace old stickUp dependency with position: sticky
From an era when we didn't have that! Now we do!

(My motivation is that I'm trying to add new JS to this page and errors
in stickUp are crashing the page early, womp womp!)
2024-02-20 18:33:23 -08:00
1e6ff4cefc Remove the Item::Translation model entirely
Okay, Impress 2020 is migrated off translations too, so we can start to
wrap this up!
2024-02-20 16:57:45 -08:00
3ac9e7ce69 Migrate item search away from item translations
Lightning fast for simple name queries now, gotta say!!
2024-02-20 16:04:41 -08:00
04af1ee319 Migrate away from item translations in misc pages 2024-02-20 15:53:56 -08:00
b7bc0ecd70 Migrate away from item translations in contributions 2024-02-20 15:52:10 -08:00
5ee3b472ec Migrate away from item translations in modeling
This one is important, I didn't notice that this is a way of setting
attributes that won't be written to both tables! `name` will only be
written to the translation table (which crashes the save), and the
other fields would only be written to the main table. Fixed! (I don't
like the super-dynamic this code was written before, anyway.)
2024-02-20 15:52:03 -08:00
0e8f457aa1 Oops, fix bug on item page now that translations aren't available
Missed this at first - now that the `name` field is just a normal field
and is always English, it's now an error to provide the locale to it as
a parameter, like we used to for the translated version of the field!
2024-02-20 15:37:07 -08:00
c75d988497 Migrate away from item translations in the Your Items feature
Just replacing references to the `Item::Translation` model to the
fields on `Item` itself!
2024-02-20 15:36:20 -08:00
a1066d9c8a Add translated item fields directly to the Item model
Like with Species, Color, and Zone, we're moving the translation data
directly onto the model, and just using English. This will simplify
some of our queries a lot (way fewer joins!), and it's what Neopets
does now anyway, and I have a secret hope that removing the complexity
along the codepath for `item.name` might help speed up large item lists
if we're lucky?? 🤞

Anyway, this is the first step, performing the migration to copy the
data onto the `items` table, making sure to keep them in sync for the
2020 app for now!
2024-02-20 15:25:03 -08:00
c215ebee09 Remove old unhelpful comment in item search
I think this was to explain why `order` wasn't part of this query, and
we probably used to sort in the controller? But now the item search
module takes care of all that, this is just confusing to say now imo!
2024-02-20 14:58:01 -08:00
0705f66f6d Add "first seen" timestamps to item pages
Impress 2020 has had this for a while, I've wanted it for reference on
occasion, let's bring it in!

Very similar logic, and Ruby & Rails's date affordances are super
helpful for simplifying how to express it!
2024-02-20 14:32:45 -08:00
e178505d2d Add redirect from openneo.net to impress.openneo.net
The homepage used to point to old projects that don't work anymore
anyway! This is the only project that stuck, so just redirect here!

We also remove the openneo.net link from the footer, because there's
nothing useful to say there anymore!
2024-02-20 10:35:59 -08:00
377df4486c Remove link to blog
It hasn't been updated in a long time, let's just be rid of it!

It's possible I'll replace it with another blog sometime if we get the
chance to do more development work, it could be a useful way to improve
communication—but not yet!
2024-02-20 10:19:41 -08:00
e991eda308 Fix minor indentation inconsistency
I recently tweaked my editor settings to make stuff like this more
obvious lol, but those are spaces in tab-indented file
2024-02-18 20:41:42 -08:00
31d033013e Delete unused AltStylesHelper 2024-02-18 20:40:55 -08:00
7efe795edb Move JS library files into a new lib folder
Just sorting things a bit cleaner!
2024-02-18 20:40:16 -08:00
1e11db93cc Delete unused modeling.js.jsx file
I think I cleared this from the outfits/new template a while ago, but
never cleaned up this file, because I was too anxious that I was
correctly identifying all its call sites. But now I'm more confident!
2024-02-18 20:38:15 -08:00
df4ea967c6 Remove now-unnecessary polyfill for the placeholder attribute
Long unnecessary, in fact!
2024-02-18 20:36:45 -08:00
95ff69ee9a Run Prettier on some of our JS assets
The motivation is that I'm about to change one of them to remove a
reference to an old placeholder library, so I want that change to be
clear!
2024-02-18 20:34:55 -08:00
0d23412fba Merge pet_query.js into its only call site 2024-02-18 20:32:24 -08:00
496b517e74 Delete unused Javascript libraries
At least, they seem unused to me on a quick audit! The scriptaculous
stuff has long been replaced by jQuery UI equivalents. (Wow, so many
generations of libraries! lol)
2024-02-18 20:30:08 -08:00
d39e7cea81 Move fundraising models into the Fundraising module
This was mostly straightforward it seems, whew!
2024-02-18 20:29:31 -08:00
82be7fe301 Move most fundraising files into a Fundraising module
Mostly this is just me testing out what it would look like to
modularize the app more… I've noticed that some concerns, like
fundraising, are just not relevant to most of the app, and being able
to lock them away inside subfolders feels like it'll help tidy up
long folder lists.

Notably, I haven't touched the models case yet, because I worry that
might be a bit more complex, whereas everything else seems pretty
well-isolated? We'll try it out!
2024-02-18 20:12:14 -08:00
1b22258576 Update special_color logic for Banana Chia Wings case
Tbh I'm not sure `special_color` is actually used anywhere? It used to
be how we decide what to show in the previewer on the item page, but
that's been replaced with the 2020 logic, so idk…

But in any case, I noticed that the description doesn't match the
pattern we have, so here's the fix!
2024-02-17 12:50:35 -08:00
6515e525fb Remove some unused PetType scopes
I looked at this and was like. "ok literally what is
`nonstandard_colors` trying to do"

reading it again now, I'm realizing the idea is that it probably runs
two queries: one to get nonstandard colors, then depends on
ActiveRecord to implicitly convert the relation to an array and then to
IDs for the second query? Instead of doing a join??

Idk, it's unused, so trash it!
2024-02-16 23:32:22 -08:00
15a905b0dd Allow modeling pets for colors we haven't gotten metadata for yet
This used to be the behavior, and the site has plenty of graceful
fallbacks for it, I just forgot this one when doing Rails upgrades!

Note that the impress-2020 stuff is *not* as graceful about this, so
the wardrobe page won't show the pet until the color is in the DB. Ah
well, still an improvement!
2024-02-16 23:28:10 -08:00
355297d977 Oops, I missed a syntax error lol
I thought this refactor of this change was working, but actually it was
just failing to build the JS lmao. Here's a version with correct syntax!
😅

Is there a syntax for this kind of thing that I'm just forgetting? Idk,
oh well!
2024-02-08 10:48:45 -08:00
46dc4cf009 Skip loading alt styles until speciesId is present
Before this change, when loading an outfit by ID, we'd send a request
to `/species/null/alt-styles.json`, which would come back as a 404,
oops lol
2024-02-08 10:46:37 -08:00
118ec6aa1a Oops, update outfit's updated_at when adding/removing items
This bug caused outfit thumbnails to get out of date, because the
outfit's `updated_at` field is used as a cache-busting part of the URL.
2024-02-08 10:32:53 -08:00
3ab6d1e3ae Oops, add some more wiring for pet state ID for saved outfits
There's an infinite loop happening in prod that I can't reproduce on
dev, but this missing piece feels like it could be related.
2024-02-08 10:15:31 -08:00
66f20747a9 Use higher-res outfit thumbnails if the device has at least 2x DPI 2024-02-08 10:07:09 -08:00
5d0848bf28 In development, use local Impress 2020 to generate outfit images
Just so we can see accurate stuff on the outfits page!
2024-02-08 10:03:10 -08:00
dc44b4dbb3 Oops, fix bug with saving outfits of pets loaded from Neopets.com
Okay right, the wardrobe-2020 app treats `state` as a bit of an
override thing, and `pose` is the main canonical field for how a pet
looks. We were missing a few pieces here:

1. After loading a pet, we weren't including the `pose` field in the
   initial query string for the wardrobe URL, but we _were_ including
   the `state` field, so the outfit would get set up with a conflicting
   pet state ID vs pose.
2. When saving an outfit, we weren't taking the `state` field into
   account at all. This could cause the saved outfit to not quite match
   how it actually looked in-app, because the default pet state for
   that species/color/pose trio could be different; and regardless, the
   outfit state would come back with `appearanceId` set to `null`,
   which wouldn't match the local outfit state, which would trigger an
   infinite loop.

Here, we complete the round-trip of the `state` field, from pet loading
to outfit saving to the outfit data that comes back after saving!
2024-02-08 09:51:31 -08:00
2667ed49ba Fully disable model translations for Color/Species/Zone
Now that DTI 2020 has been deployed without references to the
translations tables, we can stop keeping them in sync!

Next step is to drop the tables and be done with them altogether! (I
have a backup of the public data for this too, as does this repo!)
2024-02-03 08:13:14 -08:00
612cf914e0 Skip rendering layers without a usable image
This happens on the Baby Kougra, where for most poses half of the
assets have a manifest that includes an SVG but no PNG. Skip 'em!

I considered adding a glitch tag for this, but idk I think we can do
that once we're aware of an actual case where this causes visible
issues.
2024-02-01 08:55:42 -08:00
a4ca9ae522 Make the Alt Styles list less tall on large screens
On the small-screen layout, the popover goes down and covers the item
list, which isn't a big deal in context; so I want it to be basically
as tall as it can be without being unwieldy, to give more info.

But on the large-screen layout, it doesn't take long at all for the
popover to start intersecting the pet preview, because it *has* to go
up and cover the pet preview. So, I'm much more reserved about how much
vertical space I'm willing to give it!

(I also considered sending the popover off to the *right* of the button,
to cover the item list, but it felt *way* too weird imo! Especially in
the expressions case.)
2024-02-01 07:34:39 -08:00
c93895b2f7 Fix mistake in pet loading error handling
Oops, warning isn't enough, we also need to stop, right lol!

I moved this into a method, so we could `return` out of there.
2024-02-01 07:21:47 -08:00
f7fdf4e44c Don't show a glitch message for Alt Style items being Incompatible
The intent of this glitch message was that, when UC or Invisible pets
hide an item because of a zones-restrict thing, it would still show up
in the items panel as fitting a certain zone, whereas it should have
been in the "Incompatible" section and having none of its zones applied.

But the previously implementation would like, show this message even for
items that _were_ correctly marked as Incompatible? And that the server
returned no layers for, because it doesn't fit this body type to begin
with? (e.g. put a Grarrl hat on a Grarrl, then switch to Acara, and the
Grarrl hat is marked Incompatible—but would also show this confusing
message; or similarly with switching to Alt Styles)

So, when the server just returned no layers for this item to begin with,
don't show this message!
2024-02-01 07:13:04 -08:00
c7cf1d2111 Update site copy to reflect that Alt Styles are released
Announcements babyyy!
2024-02-01 06:58:54 -08:00
c13c6e7bd8 Remove the isLazy focus-management hack from PosePicker
Now that we're tracking tab state ourselves, it's pretty easy to just
pass the `initialFocusRef` to the right place instead of to both!

This helps switching between the tabs feel a lot smoother, because we
don't have to re-render and fade-in all the poses again.
2024-02-01 06:53:32 -08:00
00bc9c3bf7 Use hourglass icon for Retired UCs
The sunglasses communicated too much legitimacy lmao
2024-02-01 06:48:40 -08:00
e2d8a86f79 Add a warning that UCs are retired now
I'm keeping it in the same place for now rather than trying to fold it
into Styles, because I think that's net-less-confusing (since Styles
work pretty differently, e.g. different color requirements), and
certainly less work either way lol!
2024-02-01 06:43:14 -08:00
3a76dbb368 Show Alt Styles to all users in the outfit editor!
I think we're ready, turning off the Support-only gate!
2024-02-01 06:01:04 -08:00
453d6783c4 Move the style and state params earlier in the outfit URL
Idk I just think it's nice for them to be next to pose and such!
2024-02-01 06:00:39 -08:00
c60e222faa Add Alt Style support to outfit saving
Pretty straightforward, just add the field to the record, and wire it
all up! I'm glad this seemed to work out pretty well all-in-all 😅
2024-02-01 05:55:19 -08:00
b06149cf22 Make the "Incompatible" explainer more specific for Alt Styles
For Alt Style outfits, it's useful to call special attention to the Alt
Style feature as the likely cause of incompatibilities.

(Incompatibilities previously were most often caused by choosing a
species-specific item, then switching to another species. We generally
make it hard to enter this state, by hiding incompatible items during
search.)
2024-02-01 05:43:33 -08:00
f30213697a Clarify item compatibility in the Alt Styles explanation text
Just a lil hint that many items won't fit, in case it's a surprise to
folks!
2024-02-01 05:40:16 -08:00
cd136aa6a5 Make species/color picker smaller on small screens, to fit pose picker
Now that the pose picker button can have text content too, things were
getting pretty cramped horizontally on smaller screens! Now we use the
`sm` size when it's small-time.
2024-02-01 05:31:34 -08:00
09846a4516 Make pose picker button easier to see on light backgrounds 2024-02-01 05:26:26 -08:00
fc71f5b5a5 Filter by Alt Style in item search and item appearance API calls
I'm not planning to port full Alt Style support over to the 2020
frontend, I really am winding that down, but adding a couple lil API
parameters are *by far* the easiest way to get Alt Styles working in
the main app because of how it calls the 2020 API. So here we are, just
using new parameters for DTI 2020 that I'm gonna deploy to impress-2020
first!
2024-02-01 04:58:30 -08:00
578528f468 Better handling for items in different zones with the same name
Specifically, I was looking at the new "Stormy Cloud Kacheek" items,
and was surprised to find that, in the outfit editor, they all get
grouped under "Markings" (and therefore the UI treats them as
mutually-exclusive via hidden radio button and only bolds one at a
time), but they aren't actually conflicting because they occupy
different zones named "Markings".

In this change, we make the zone groups actually just be *by zone*
rather than jumbling all of the zones with the same label together; but
in most cases, we still keep the same simplified display. In the case
of the "Stormy Cloud Kacheek" items though, we now get a few groups:
`Glasses`, `Markings (#6)`, and `Markings (#16)`. Glasses is chosen
by coincidence because it's the first zone label for that item
alphabetically (even though that item also occupies a third "Markings"
zone), and then the other two know to disambiguate from each other.

There's an opportunity here to cheat things further, like to
*intentionally* select items like "Glasses" that are less ambiguous
when possible. I'm not aware of enough other cases like this for that
to really matter, though, so I'm just leaving it as-is!

I tested this a *bit* on other outfits, and everything looked fine at
a glance, so I'm just moving forward—but I'll make an announcement to
ask people to help take a look!
2024-02-01 03:14:00 -08:00
cb90b79efe Remove logic to auto-detect Unconverted pets (fixes Baby Pteri bug)
Two motivations here:

1. Unconverted pets should no longer exist on Neopets.com (and we
   especially don't expect new ones), so this logic helps no one.
2. The Baby Pteri keeps getting overridden to be marked as Unconverted
   because it has only one asset, which is incorrect.

A decent heuristic for a bygone era, goodbye!
2024-02-01 01:40:50 -08:00
b50bf6ceb8 Add SVG support to alt styles
Just moving our hacks around and adapting them to the SVG case lol!
2024-01-31 03:02:19 -08:00
ab8c9f6242 Oops, remove alt style when switching species
This wasn't causing big problems because we made resilient little
choices in a lot of little places… but it's confusing as a potential
state, and the Styles chooser wasn't selecting the "Default" option
after you switch—which is what tipped us off!
2024-01-30 07:21:14 -08:00
c2de6f7167 Display alt styles in outfit editor when selected
Yay it works(*)! But two major missing pieces:

- Outfit saving doesn't persist it at all
- Item compatibility is unaffected: items will still appear in search
  and in the preview, even when they don't fit anymore.
2024-01-30 07:01:03 -08:00
3ebbfc4967 Move alt style state into the outfit state
This still doesn't _do_ anything, except that you can see the URL
change when you switch between styles. Just a step forward is all!
2024-01-30 06:21:32 -08:00
741d52175b Open the pose picker to Styles if there's an Alt Style applied 2024-01-30 06:04:35 -08:00
8e5939e408 Show alt style name in the pose picker button when selected
To help with space, I'm just showing the word "Nostalgic" (or "???" if
it's from a series we don't recognize, this is hardcoded by ID), and
trusting that from context it will be obvious that it's the "Nostalgic
Faerie" case or whatever. (Moreover, in both the button and the select
we're omitting the species name, by similar reasoning!)

Note that this _still_ doesn't actually apply the style to the outfit
whatsoever; this is all just local state as we're continuing to play
with UI concepts. Actually applying it is probably next though! (Though
there's a couple more UI things I want to do, like some affordances to
clarify that a Style is applied and that Expression changes won't work.)
2024-01-30 05:55:19 -08:00
33bcabab83 Overhaul pose picker button to have text now, for all users
This one isn't reserved just for Support users! I think this button
stands out a lot more with the text, and I want people to be able to
discover it!
2024-01-30 05:38:19 -08:00
4025dcd968 Oops, fix crash on unknown pose case
Right, I was playing with the paintbrush but didn't end up using it!
Let's uhh go with the smile as the default, I guess?
2024-01-30 05:06:26 -08:00
bc77c261fb Set initial focus when opening the PosePicker to the Styles tab
Later on I'll want to control the picker to open to Styles if a style
is selected, or to Expressions if not.
2024-01-29 09:17:09 -08:00
bdfa3aad0b Oops, fix bug in alt styles query loading state
Oh right, React Query's API is slightly different, fixed! (Previously,
this would cause the PosePicker to show before all the data was ready,
so alt styles would sometimes pop in after the popover was already
open.)
2024-01-29 09:10:26 -08:00
8f934e83b8 Move Expressions/Styles tab to the top/bottom depending on placement
On small screens, the PosePicker opens down, and we put the tabs on the
top, to be near the button.

On large screens, the PosePicker opens up, and we put the tabs on the
bottom, to be near the button.

Previously, we always set `placement="bottom-end"`, which on small
screens behaved as written, and on large screens there would not be
space to open downward so it would open upward instead.

Now, we set the placement explicitly based on a media breakpoint, and
we change the `flexDirection` of the tabs container on the same media
breakpoint.
2024-01-29 09:09:09 -08:00
49158b2c54 Make the new pose picker button text support-only
I'm playing with using text to call more attention to this button, but
I'm not altogether pleased with the design yet. I'll leave it there for
me and Support users, but hide it for most people until we've got a
more complete concept.
2024-01-29 08:45:22 -08:00
207c65f209 Link to the Styling Chamber 2024-01-29 05:36:48 -08:00
433a14104f Hide the WIP Styles UI behind support staff flag
That way, I can stop being on a branch and be working on main, and
deploy stuff to preview live, without having to share it with everyone
just yet! (This was the motivation for finally adding Support tooling
to main DTI lol!)
2024-01-29 04:36:48 -08:00
514c99fb42 Add WIP styles tab to the pose picker
It shows the styles! You can select between them, but it currently does
nothing, womp womp!
2024-01-29 04:26:40 -08:00
e2ab8bbc9c Start adding Styles UI to pose picker
Add the tab UI, though the styles aren't in it yet; and add text label
to help make the whole UI more discoverable.
2024-01-29 04:26:40 -08:00
57beca1b3c Refactor PosePicker a bit
Just extracting some things to make the main function body leaner so
it's easier to add the alt styles stuff.
2024-01-29 04:26:40 -08:00
32f5d6d4a0 Show the PosePicker, even if there are no standard poses labeled
This is because I'm gonna put alt styles in here too, and I figure it's
reasonable to just explain what's going on.
2024-01-29 04:26:40 -08:00
4fff8d88f2 Add support_staff flag to user record; they can use Support tools
A little architecture trick here! DTI 2020 authorizes support staff
requests by means of a secret token, instead of user account stuff. And
our support tools still all call DTI 2020 APIs.

So here, we bridge the gap: we copy DTI 2020's support secret to this
app's environment variables (I needed to update
`deploy/files/production.env` and run `bin/deploy:setup` for this!),
then users with the new `support_secret` flag have it added to their
HTML documents in the meta tags. Then, the JS reads the meta tag.

I also fixed an issue in the `deploy/setup.yml` playbook, where I had
temporarily commented some stuff out to skip steps one time, and forgot
to uncomment them after oops lol!
2024-01-29 04:21:19 -08:00
72d4bc65ae API endpoints to load alt styles as JSON, and filter by species
Gonna use this in the app for the alt style picker! Still deciding on
the UI details.
2024-01-28 07:30:06 -08:00
6763e9454e Optionally use local instance of impress-2020 during development
To activate this, I created a `.env.development` file in my project
root, with the following content:

```env
IMPRESS_2020_ORIGIN=http://localhost:4000
```

Then, I started impress-2020 with `yarn dev --port=4000`.

Now, the app loads from there, hooray!! It even fixes that obnoxious
pet state ID bug that happens when you run against the production db lol
2024-01-28 07:00:29 -08:00
4eb4013eb2 One more copy edit, alt style nuances are hard to explain… 2024-01-24 08:39:18 -08:00
64debe573a One more alt styles explanation copy edit 2024-01-24 08:23:43 -08:00
362e2ab4e7 Add more notes about the state of alt styles to the alt styles page 2024-01-24 08:17:13 -08:00
6206be6c03 Left-align the alt styles on the page, to flow better with the headers 2024-01-24 08:02:19 -08:00
495366e73e Group alt styles by species 2024-01-24 07:53:37 -08:00
7a1239ae5a Strip spaces from thumbnail URLs for colors like Usukiboy 2024-01-24 07:27:07 -08:00
fd729916d7 Specify width/height for alt style thumbnail image
to avoid reflows!
2024-01-24 07:26:44 -08:00
0bbbe67953 Add note about style tokens not being available on trade lists 2024-01-24 07:22:08 -08:00
43d650a5d4 Better alt styles page layout
I had tested this with less variety in the list of styles, now that I'm
seeing it live I realize we need more consistency and more space!
2024-01-24 07:03:28 -08:00
394cc212b3 Add Styling Studio page to show the styles we already have modeled 2024-01-24 06:53:37 -08:00
ba45de583f Oops, don't update body_id when there's an alt style! 2024-01-24 06:12:35 -08:00
40278afd0c Add find_by_name method to AltStyle 2024-01-24 06:12:03 -08:00
e511bdc5e2 Oops right, it's okay to work with an alt style we've already seen! 2024-01-24 04:01:34 -08:00
4e5023288e Track contributions of Alt Styles 2024-01-24 03:54:43 -08:00
5004142dfb Add alt style support to modeling
Nothing to show them yet, but I think this works for loading it all in
the first place?

Still needs contributions tho!
2024-01-24 03:25:23 -08:00
ec3bb7dbe0 Update NC UC announcement 2024-01-24 02:15:50 -08:00
4888a9dcbe Oops, remove stray viewer_data reader from Pet
This is left over from a previous plan I had, before moving
`fetch_viewer_data` to a class method.
2024-01-24 01:00:53 -08:00
b24ed7facb Re-enable pet loading, now that we're filtering out alt styles for now 2024-01-24 01:00:25 -08:00
b0e7f2ccd5 Move lib/rocketamf -> lib/rocketamf_extensions, to fix reload issues
Something in the Rails loader doesn't like that I have both a gem and
a lib folder named `RocketAMF`, I think? It'll often work for the first
pet load request, then on subsequent ones say `Envelope` is not
defined, I'm guessing because it scrapped the gem's module in favor of
mine?

Idk, let's just simplify all this by making our own module. I feel like
this old lib could use an overhaul and simplification anyway, but this
will do for now!
2024-01-24 00:59:11 -08:00
0406a32444 Disable loading alt style pets specifically 2024-01-24 00:54:30 -08:00
c33f1cb767 Extract Pet.fetch_viewer_data to a class method
This will make it easy to look up pet data from Neopets without messing
around with how the Pet model handles it!
2024-01-24 00:51:20 -08:00
c76e8cd2a9 Allow admin users to load pets
Also allows the new rake task we're building to load, too!
2024-01-24 00:42:35 -08:00