I want to test some logged-in stuff, but the whole openneo_id app is a mess to integrate with (and I want to eliminate it down the line anyway), so here's a simple hacky thing that just gets you into a test user for development!
During this upgrade process, `rails server` hasn't been updating its logic when files changed, so every change had to be accompanied by a restart.
This turned out to be because Vagrant's networked filesystem to share between the host and guest systems doesn't support the filesystem update events Rails is listening for. So, we switch to a simpler file watcher that does more work but doesn't depend on the filesystem events!
It's unused, and I'm just double-checking that it's not somehow causing the issues with the rails dev server not reloading classes. (The `threadsafe!` option would do that, but I don't thiiiink this is the env we're running? But I'm wondering if the loader is getting confused by the prefixiness of the name or something. Unlikely!)
This is recommended by the Rails 4.0 upgrade guide:
> The caching method changed between Rails 3.x and 4.0. You should change the cache namespace and roll out with a cold cache.
I noticed too that old cache entries with old character encodings were a real problem, so yeah making sure we're working with a cold cache is smart!!
Not being a subquery is better! I realized later that a LEFT JOIN would probably do it even betterer? with like `HAVING count(x) = 0`? but the `left_outer_joins` method doesn't seem to be in Rails 4, and I don't want to do stringy joins, so this is fine for now!
Right, previously we were querying "has *at least one asset* that is not in zone X" instead of "has NO assets that are in zone X".
I don't know a fast way to query for that, this will have to do for now!
Not doing the tricks with `is_positive` anymore, instead just calling different functions altogether at the call site.
Also, instead of classes, I feel like this is a lot more concise to just write as class methods that create certain instances of a trivial `Filter` data class. Without the tricks of `is_positive` in play, the value of classes goes way down imo.
Ohh ok, without this change all of our `scope`s were just immediately evaluating the argument and fetching _all_ such matching records immediately, instead of waiting to actually be called. This led to bugs like `pet_type.as_json` returning ALL pet states in the whole db, because the `PetState.emotion_order` scope was being treated as a single predefined query, rather than a query fragment to merge into the current context.
This also explains what happened in 724ed83: that's why things before the scope in the query were being ignored.
lol again this is hard to test so uhh I hope this didn't break it all!! though tbh I feel like we removed this feature or something anyway? idk it stopped working in some way
Tbh I'm not 100% sure this is a fix, I'm not sure what `haml_concat` was doing here, and the page is still crashing so it's hard to say. But fingers crossed!
Idk why, but when the `select` was the first thing in the query, it was getting ignored. I wonder if there's something about the `object_assets` scope that I'm not understanding that's overwriting it? Or the `joins`? But whatever, this works, I'm not worried about it for now!
The controller was like "oh yeah we have that cached" (from previous renders of the app on Rails 3 I think?), but the view disagreed, bc it was appending a template digest to the cache key. That's a smart feature, but not compatible with how we skip queries in the controller, so disable it for now!
Rails 4 removed `attr_accessible`, and we should move away from it to (I think we'll need to by Rails 5?), but for now we can install this and move on!
We'll need to replace the item search query stuff with direct MySQL queries, but that's not ready yet bc the app still isn't booting, so we're committing this in a known broken state for now!
I haven't logged into newrelic in a billion years, let's just stop sending them stuff
(This is a precursor to an attempt to delete flex stuff too and replace our elasticsearch stuff with direct mysql queries like Impress 2020 does, but that'll be more work!)
I guess the APIs changed here, but these were placeholder settings we weren't actually using anyway (cuz we use the OpenNeo ID integration), so I just commented them out and it seems fine for now!
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.
Rather than figure out how to upgrade the Stripe gem to be compatible with future Rails, I'd rather just delete the references, since it's currently unused.
I'm not so bold as to go in and fully trash all our donation code; I just want to ensure we're not sending people down broken codepaths, and that if they reach them, the error messages are clear enough.
I'm just giving the app a very quick scan on critical pages, it's possible I'm missing some issues on paths that are harder to test rn like openneo_id auth, but I'll check in on that later I think?
These are necessary for installing some of our gems!
Note the tricky bit where we need an older OpenSSL package when building Ruby 1.9.3, but need to uninstall before `libmysqlclient-dev`, which requires a more recent version of `libssl-dev`. I thiiiink this is safe to do, but we'll find out!
None of these are private repos, so there's no reason to use the authenticated git protocol to download the stuff. (I guess this used to work because I had github creds set up on the machine that was running the app, whereas right now it's running in Vagrant, so yeah makes sense that it wasn't an issue before!)
I'm pretttty sure we fully do not need these, they were an attempt to solve the "contacting neopets.com is slow" problem, which we now solve by having other processes who are better at concurrency handle that request.
The intent is to set up for an upgrade of Ruby and Rails to the modern versions, but I want to start by having a stable running copy that we can incrementally pull up to new versions of things!
And it turns out getting Ruby 1.9.3 to build on modern platforms is hard! I started by trying on macOS and just couldn't get there, the instructions I found for workarounds didn't seem to work anymore.
So the solution I landed on was to set up an Ubuntu VM, and follow some instructions from https://stackoverflow.com/q/51986932 to patch Ruby to work with the version of OpenSSL we have access to!
And it was enough of a challenge that I figured that, rather than setting up the Vagrantfile elsewhere, it would be helpful documentation to do it here, even if we scrap the Vagrantfile etc later once we're in a new stable environment.
