@yoyodave42 any thoughts on this?
2 Likes
I think the museum is gone. The PHP script is so old it is a security risk to any server running it.
The current server took it down for that reason.
Rick Brough is running it at present. I’ve been out of it the last few years. Not sure we have any options.
David
4 Likes
Dave I hate to hear that. That website have very valuable information on that site.
2 Likes
Well that’s a drag.
3 Likes
Oof. This is a major, major loss. I’m not even remotely a comp sci/web dev oriented person, so I’m sorry if anything I say/ask sounds dumb… but I guess the major question I have is, is all of the data from the site (like, specific entries for example) still present/stored somewhere? Or is it just gone?
The WayBack Machine archive is usually a great go to in scenarios like this, but unfortunately b/c of the drop down menus, it’s not able to pull up any specific entries (at least for me).
I would hate for lots of important history to be lost in this situation. I’m gonna page @Isaac, as from what I recall they’re quite a bit more knowledgeable about this sort of thing than I am (IIRC they were at least wanting to prevent this same situation happening but with YYN).
Can any other web dev knowledgeable people chime in? This is super important stuff here for our hobby and we should get it figured out sooner than later.
3 Likes
If there’s a database backup a modern replacement frontend/backend could be built on top of it. @yoyodave42 do you know if Rick has a recent backup? Or any backup even?
I still need to reach out to JD to see if I could get a copy of the YYN database, I really hope to be able to archive it one day, there is so much information in there.
3 Likes
I’ve reached out to a professional Web Developer contact of mine who had a look and this is the information I received, hopefully it’s useful. This is what they said:
“The site is custom coded and it looks like it does not support the modern version of PHP or browsers are blocking the site as it is using the ancient version of PHP.
I think the data should be kept on the database on the backend. It will be best to plan for the migration to export the data before it is too late.
The website owner can try to downgrade the PHP temporarily to make the site active again. This needs to be done from the hosting side.
Downgrade the PHP to the old version.This will bring back the site so the owner can try to copy over the contents manually.
Or the database needs to be backed up and migrated.
This will be tricky as the site is very old and custom built. Someone needs to go through the database and try to analyse how the coloumns and tables are related. It will be like looking at multiple spreadsheets and someone trying to figure out what that information is, and where it belongs.
So the process will be:
- downgrade PHP to bring back the website or backup the database
- develop a new website
- import the backed up data to the new website”
7 Likes
This was my fear, downgrading the PHP version to whichever it previously ran on shouldn’t be too hard but going through old database might be. Idk unfortunately, this isn’t my line of IT work or id be all over it
2 Likes
I’ll come at this as a cyber security engineer. This site has probably been a problem for years if it’s been on an old insecure version of php. I would bet the hosting platform has informed the site owners of the intent to force an upgrade and the deadline has no passed. The site is there I assume the data is still present just unreachable from the front end due to the incompatible php versions.
Salvaging the site should be possible if someone can get the backend data but it won’t be a quick and easy task.
I would bet the hosting site will have no interest in fixing this from there end. It’s a risk and impacts vulnerability scans which can put them in a bad place for compliance or make there customers frustrated. Always worth asking though. Never know if you get an engineer that happens to also like yo-yos. It would be temporary though.
4 Likes
Yeah, also doubt they’d downgrade the version of PHP for the reasons outlined here. Priority number one should be figuring out if there’s still database access and dumping it or hopefully finding a back up.
But like you said doesn’t hurt to ask, if it works out and the museum is brought back up temporarily and if there’s no access to a database dump, we could write something to scrape all the pages from the website which would be as close to a database backup as we could get without actual access to one.
4 Likes
Yep, my thoughts exactly if we can’t salvage then we could scrape the entries and rebuild later if a temporary fix could be made… either way I would assume the backend is intact and fine and if that’s the case lots of options on recovering the data it’s just a time commitment at this point.
I’m not a developer so the scraping is outside of my scope. I’ve done some DB work in the past but leaned hard into networking and cybersecurity and honestly the last half a decade I’ve been a “leader” role not a contributor, so my skills are rather dated and rusty.
I’m really good at telling people what they should be doing and how to get on the right path. I’m less competent at this point on the doing of the things lol.
3 Likes
Hey guys I know we have people looking into it and everything but just a update, up I’m sending the website data over to my dad to look at as well. He’s a VP of global services at an IT company and he’s been doing it for over 20 years. He’ll be able to read the data and all the stuff I’m unable to (I’m only learning to code and do cyber security I don’t do websites or development). He or even one of his guys should be able to at least answer if it’s salvageable or if making a new website is a possibility/the right move. I just wanna save this stuff man that really sucks it’s gone.
2 Likes
You and i seem like we’re almost in the same boat here lol
1 Like
A free wiki may be a better long term destination for this content as it would enable many people to easily manage the content and wouldn’t rely on someone to pay, host, code, patch, backup etc. Ive done IT work for 23 years and can rebuild the site, but a custom code solution is a liability.
6 Likes
I thought about a wiki page a lot I was just worried about the free will editing
edit with approvals enabled would be the safest path for a wiki but that adds overhead that or make sure the wiki has revision history features so bad edits can be reverted easily.
There’s a meta “author” tag with an email in the page’s source (chimera@the museum’s domain), I sent an email to the address about the site and linked this thread, couldn’t hurt I guess; maybe @Chimera is the same person too so tagging them as well.
ETA: ah thanks for tagging them @MattC , the email to the address in the source bounced
not to be a downer but your dad or his team won’t be able to provide any info that’s not already in the thread; just like us they don’t have access to the backend and without hearing from the developer Rick all we can do is speculate about what might have happened and what we can do. I think their last name was posted in this thread or a related one so we should check if they’re on Facebook in the big BST group as well.
2 Likes
2 Likes
I’m all for a wiki as well but that wiki still needs to be hosted, backed up, and maintained which aren’t free costs. Using something like Fandom (ie the existing yo-yo wiki) could work but it leaves Fandom in control of the data. Maybe they provide an export function though? They’re built on MediaWiki IIRC so if there’s a way to export or back up the data then that could work since we’d be able to migrate to a self-hosted option if needed down the line.
Custom code isn’t terrible as long as it’s open-source which doesnt seem to be the case here tbf. But yeah using software that’s well-known is much easier to hand off between maintainers and should be highly considered if a new site needs to be built.
1 Like
You’re right and that’s exactly the answer I got from him lol
2 Likes