Commit graph

40 commits

Author SHA1 Message Date
abfe1e6df7 Extract neopets_origin into a config value 2024-10-18 18:00:48 -07:00
7f55456454 Explicitly disable the unused ActionCable Rails feature
Just for consistency with the other features we're not using, we turn
off ActionCable when loading the app. I just removed
`config/cable.yml`, so I figure, let's not load a feature without the
config file it expects! (even though that didn't seem to bother it)
2024-09-20 13:14:00 -07:00
5bf2ef42a0 Move JS libraries to vendor/javascript
The silly motivation is that I wanted to remove `.prettierignore`,
which just exists to omit that one folder from `npm run format`. But it
also seems like this is the standard place to put them—a standard
created long after we first set this up lol
2024-09-13 21:16:46 -07:00
0a5d369735 Remove i18n locale config complexity we don't use anymore
I forget what this was for, I think part of it was for managing item
names in different languages, and the "private" locale thing was
probably for WIP locales? But yeah, not used, delete!
2024-09-13 20:55:09 -07:00
874483eacb Fix SassC::SyntaxError when compiling perfectly valid CSS files
Okay cool, so this was an error that was happening *only* when building
assets for production: Sass's CSS minifier isn't familiar with all
modern CSS syntax (I think is the issue?), and so errors on things that
are actually totally okay.

I had previously worked around this in `swf_assets/show.css` with an
equivalent syntax that Sass recognized. But in this latest case with
the new `fonts.css.erb`, it was upset about the `src` list for the
fonts, and I don't know a workaround for that.

So, let's just disable Sass's CSS minification for now. I imagine the
difference isn't huge when CSS compresses just fine with gzip anyway?
(Most of what you can "minify" in CSS is whitespace, and that largely
seems silly to me when gzip is running.)
2024-09-09 19:59:43 -07:00
a9f44c0aa6 Configure the application's default time zone to NST (US Pacific)
This doesn't affect a lot right now, it was previously defaulting to
UTC I think? And I've confirmed that, while timestamps are stored in
the database as UTC, they're not interpreted any differently with this
setting. (Or, rather, it's loaded as a `DateTime` object for the same
moment in time, but in the NST time zone. Good!)

But this feels like a more useful default for displaying things for
development etc, and moreover, I'm working on some logic for things
like "when do limited-time Dyeworks items expire exactly?", and that
logic is made *much* simpler if we can just compare dates in NST by
default rather than fudge around with the zones on them and figuring
out the correct midnight!

(Although, as I type this, I think I maybe have thought of an easier
way to do it? So maybe this change won't actually be necessary for
that, but it still feels like a more sensible default for us
regardless!)
2024-06-18 16:39:37 -07:00
7515527555 Oops, add ActionCable back to the app
Turbo expects this to exist, for features we don't use! I didn't bother
to check if Turbo has a way to turn this off too, I just said fine lol

Turbo worked in development without this because it only loads files as
needed, whereas in production it blocked the app from starting up. But
you can see the error in development by running `rails zeitwerk:check`,
which attempts to preload everything to make sure it all works, and you
get this:

```
NameError: uninitialized constant ActionCable (NameError)

class Turbo::StreamsChannel < ActionCable::Channel::Base
```

Fixed now!
2024-03-13 17:48:25 -07:00
76af587e7c Replace falcon server with puma
Been wanting this for a while in theory, gonna actually do it now!

The motivation is that I want to turn up the timeout for loading pets,
because the Neopets endpoints are slower today with the NC UC release -
but I can already predict that under our current architecture that will
be a problem, because it'll block up our request queue!

Falcon uses Ruby's relatively-new async system to *not* have requests
block on upstream requests, and my understanding is that this behavior
is plug-and-play. Let's see how it goes!
2024-01-23 21:55:26 -08:00
e337767954 Fix "couldn't download the associated Flash files" when modeling
So this was a slightly wrong error message, what was happening was:

1. Trying to load the image hash for this pet, by looking them up at
   https://pets.neopets.com/cpn/PET_NAME/1/1.png and seeing what URL it
   redirects to.
2. But pets.neopets.com was rejecting our User-Agent string, which
   would've been just "Ruby", since we hadn't set it otherwise. I guess
   that's an explicitly banned string?

I also found that the kind of more-helpful User-Agent string I like to
write was being rejected, and I could only get it to accept something
very simple? So that's what we're using now, I guess!!
2024-01-15 01:15:35 -08:00
e22809deb3 Disable some unused Rails features
I noticed when running `rails routes` that there's a lot of routes for
major unused Rails features, like storage. I didn't look deeply enough
into ActiveStorage to know if I was risking accepting arbitrary file
uploads, I just figured, if I disable it (which simplifies the app
footprint anyway), then I can be certain! So, goodbye!
2023-11-11 15:12:41 -08:00
56ce32b6cb Upgrade to Rails 7.1.1
The usual stuff! Installed the new gem and its new deps, ran
`bin/rails app:update` and did my best to manually merge the dev/prod
config files with the new canonical defaults, deleted some migrations I
don't think are relevant to us, and yeah!

Also, Rails 7.1 seems to need `libyaml-dev` installed, so I added that
to the `deploy/setup.yml` playbook!

One thing to note is that, while I was here, I turned on some settings
relating to our use of SSL that technically weren't on before. This
should be fine and helpful? But if stuff breaks, well, check those!
2023-10-25 15:05:31 -07:00
7e922503b5 Upgrade to Rails 7.0.6
Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
2023-10-23 19:05:07 -07:00
59efb49419 Upgrade to Rails 6.1.7.4
This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
2023-10-23 19:05:07 -07:00
be7e11a0d0 Upgrade to Rails 6.0.6.1
Another pretty easy one! We have the `rails app:update` changes in here too.
2023-10-23 19:05:06 -07:00
86edc8584f Run rails app:update
We accepted some changes as-is, but for development.rb and production.rb we read the diff and manually edited them!
2023-10-23 19:05:05 -07:00
d97c32b5da Upgrade to Rails 5.2.8.1
Some important little upgrades but mostly straightforward!

Note that there's still a known issue where item searches crash, I was hoping that this was a bug in Rails 4.2 that would be fixed on upgading to 5, but nope, oh well!

Also uhh I just got a bit silly and didn't actually mean to go all the way to 5.2 in one go, I had meant to start at 5.0… but tbh the 5.1 and 5.2 changes seem small, and this seems to be working, so. Yeah ok let's roll!
2023-10-23 19:05:05 -07:00
685ac2b4ad Make 4.1 -> 4.2 changes
Just following the recommended stuff in the upgrade guide!
2023-10-23 19:05:05 -07:00
Matchu
a4a0188b1b Stop caching trade users on item page
Idk this one might actually be a bit of a pain to load? But I'd want to optimize it differently anyway, and there's overhauls we're already planning to do here.
2023-10-23 19:05:04 -07:00
Matchu
44341ba731 Stop caching pet type images on item page
That's easy queries and easy templates!
2023-10-23 19:05:04 -07:00
Matchu
b87492d4ee Stop caching item page contributors
This lets us remove the contribution observer too!
2023-10-23 19:05:04 -07:00
Matchu
0eea2c9652 Oops, remove item_observer from config 2023-10-23 19:05:04 -07:00
Matchu
72a08901c8 Upgrade to Ruby 2.2.4, Rails 4.0.13
NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix!

```
/vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError)
```

But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
2023-10-23 19:05:02 -07:00
eda80a8dc7 double whoops; the actual problem was that i hadnt restarted the background workers :P 2014-04-05 23:52:24 -05:00
9fe19e00c7 whoops; now that we index by item fit, update item after asset save 2014-04-05 23:48:36 -05:00
63b34435c7 ugh, add react.js manually :( 2014-01-20 14:35:28 -06:00
7928514342 add react.js to precompile list 2014-01-20 14:18:30 -06:00
6b340f906e Cache trade info on items#show, finally! I think it's the performance culprit. 2013-12-27 14:49:46 -05:00
f07996d762 cache pet images on items#show, in case that's what's being a super-slow jerkface 2013-12-05 15:22:43 -06:00
abe35c6fd9 throttle pet loads per ip 2013-07-02 14:10:01 -07:00
c7237d7d44 fix a bunch of precompiled-asset-missing errors 2013-03-05 22:26:14 -06:00
59be3c9d66 faster asset compilation by not initializing app 2013-03-05 21:52:31 -06:00
cf5191d33c phew. rails 3.2.12, including some asset pipeline. still buggy. 2013-03-05 20:08:57 -06:00
f547a75c40 ruby 2.0.0 compatibility... hopefully. 2013-02-25 01:14:45 -05:00
0db1bb8d74 enable fallbacks 2013-01-11 15:26:07 -06:00
99669b8e4e cache homepage latest contribution 2012-08-09 22:59:35 -04:00
1e3938eea9 improve closet performance by caching item link 2012-08-09 19:34:56 -04:00
374e85f9d0 drop in redirect image url for urls blocked on petpages 2011-08-02 20:01:48 -04:00
ca155314fa home page caching, reset top contributors only when necessary 2010-12-11 09:37:39 -05:00
ca9e1fb0ca cache item show pages as a first try :) 2010-12-08 20:15:46 -05:00
87fc4bdf05 rails 3 2010-05-14 18:12:31 -04:00