Commit graph

1954 commits

Author SHA1 Message Date
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
abbde80f60 Install MySQL server during deployment setup
It's finally colocated onto this box, instead of being on the old
server! I think I'm noticing substantial perf improvements, probably
both from increased colocation (tho they were in the same house
before), and also from like ten years of performance optimizations LOL!

As part of this, I created a new `setup_secrets.yml` file that's
similar to `production.env`, but is for values that the setup script
itself needs access to, whereas `production.env` is for values that the
app needs at runtime. (Though they have some things in common, like the
MySQL user password!) It's gitignored for security, as per usual!
2024-02-19 13:21:24 -08:00
ead0003397 Add custom 502 error page, for when the app goes down but nginx is up 2024-02-19 13:19:31 -08:00
a6daef636c Extract error-grundo.png into an image file
Initially I put this all in the same thing cuz I wasn't sure I could
count on our nginx config to actually serve asset requests correctly…
I've figured it out now!
2024-02-19 11:19:28 -08:00
aa108190b6 Oops, only redirect to maintenance.html internally
Oh I see, if I start with a slash, then it's interpreted as a reference
to a file; whereas if I don't, it's interpreted as a URL redirect. Ok!
2024-02-19 11:18:28 -08:00
7c36ba81e5 Minor change to explanation text in authorized-ssh-keys.txt 2024-02-19 11:12:40 -08:00
974aaa48ff Add maintenance.html page 2024-02-19 09:45:45 -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
93bc300940 Update SMTP settings
I moved `@openneo.net` mail to Fastmail instead of Dreamhost, so this
setting needs to change to match!
2024-02-18 14:15:23 -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
e9b0fa0779 Future-proof our nginx config for IPv6
Today I learned that nginx requires a special invocation to listen to
IPv6 addresses as well as IPv4. On some of my other projects, this was
causing Let's Encrypt certificate renewal to fail, because Let's
Encrypt prefers to connect over IPv6 when an AAAA record is present, so
its challenges were always returning 404, because nginx wasn't
listening on IPv6.

This shouldn't be affecting impress in production, because we don't
have an AAAA record right now. But I'm just making this change in all
my projects, to make sure this doesn't bite me in the future!
2024-02-13 08:52:45 -08:00
95949da6f9 Create swf_assets:remove_duplicates task
I'm not sure where these duplicate records have been coming from over
the years (I checked the timestamps and it's been happening
occasionally since 2013 up to late last year, there were ~1,600
instances), but for now let's just get rid of them!

This is related to the issues we've been addressing lately where some
biology assets have manifests but no PNG specified in them: the older
copies of the assets would have our generated PNG as a fallback, but
the newer copies would get served as part of the pet appearance *in
addition to* the older copies, and the newer copies would be marked as
having no DTI-generated image, which our system wasn't always able to
handle.

We've primarily been addressing this by leaning into more graceful
failure modes of skipping certain layers, but… these layers *shouldn't
be here*, and are cluttering up support tools and such; let's be rid of
them!

I ran this today seemingly without issue, but I kept a backup of the
`yarn db:export:public-data` task in `impress-2020` to be able to check
and rollback if we discover a mistake.

One last note: the `ORDER BY` clause in the `GROUP_CONCAT` call was a
late addition, *after* I ran this in production. Scanning the console
output, it seems like ordering by ID was MySQL's default behavior here
anyway (makes sense!), so I'm not gonna bother to rollback and re-run,
but I think specifying this is helpful to ensure we're not depending on
unspecified behavior and to be really clear about our intentions of
which record to keep (the one with the smallest DTI ID number).
2024-02-09 09:53:41 -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
566ac241a1 Remove stray comment about the puma gem
Oh right, I deleted `puma` but not this comment about deleting `puma`,
lmao
2024-02-03 08:23:21 -08:00
8aa6eb40a7 Disable advanced mini-profiler tools in production
I'm not really using this lately, and it _only_ creates vulnerability
surface area when not in use; so, while I'm pretty sure we locked this
down correctly to only admin accounts, I'm disabling it just as good
practice. We can add this back later if we need it again!
2024-02-03 08:21:14 -08:00
d6b6ab884d Migration to drop {color,species,zone}_translations
They're no longer referenced in either app! Begone!

(The translated values are still available in the DTI 2020 repository's
history, under `scripts/db`!)
2024-02-03 08:20:18 -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