NineChime forum
Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
- Index
- » Wacintaki support
- » Missing oekakidta table
Post a reply
Topic review (newest first)
- Waccoon
- 01-29-2022 04:57:35
Yeah... don't bother recovering the thumbnails. The bottom of the Wacintaki control panel has a feature to rebuild thumbnails either for the first page or all pages. As long as the information for the original images is in the database, fixing thumbnails is a piece of cake.
From what I can see based on a quick peek, the Wayback Machine only has 9 or 10 front-page snapshots cached, so it doesn't look like there's much data that can be recovered. That's probably good for about 50 picture slots archived. By default, Wacintaki installs supported 300 images before recycling slots, so even in the best case scenario, that's the max you can expect to rebuild. Oekaki's heyday was between 2005-2010, and back then most of the free hosting services offered about 100 MB of space, so I figured a margin of 300K per image slot with database overhead was reasonable. Wacintaki was always maintained on the assumption it would be used on a free, shared hosting service, and most of them were pretty terrible.
Anyway, I'm not adding any new features to Wacintaki, but it's still maintained and I do still fix it now an then to accommodate new versions of PHP. The PHP people are pretty much idiots and keep breaking major stuff in new releases, so fixes are a must. I can't believe they totally busted array iteration in PHP 8. What do you do, huh?
- Blue
- 01-28-2022 13:34:20
Ugh. Been there a few times. Server migrations are not much fun and service provider changes are even worse.
This is really good info. The updater did not seem to properly upgrade the tables to UTF-8, but it was no problem to take the SQL statement snippets from the upgrade.php file and use them as SQL statements in phpMyAdmin to properly add any new or missing tables.
Since the oekakidta table was completely missing in the as-found, I was hoping that the first post in the oekakicmt file *might* be the original post info. I actually tried to copy the first posts from the cmt table to the dta table with a well-crafted SQL statement, but as you mentioned (and can likely guess), the primary key is duplicated in the cmt file to tie them to the original post... I did manage to stuff dta with unique data by doing a csv backup of the cmt table, doing some "Excel Magic" and putting the result into the dta file. This made for a huge list of items to "recover" in the web interface. But, the "recover" just nuked the bad entries int the dta file lol. So, I just restored from the backup I made just prior to trying that and am back at empty working 1.6.7.
Not super excited about the idea of pulling each and every page from the Wayback Machine and restoring each by hand. But, am not *entirely* opposed to the idea, either. It is just time that that needs to be carved out. It is oddly therapeutic, even though I am relatively certain that nobody else really cares.
I did do something similar after a service provider change when about 3 or so weeks when a different forum's data just went *poof*. Google cache was my best friend at that time - I could actually save the pages, copy and paste them as new posts, then use a phpBB mod I found to both change the post date and author to "inject" them into the correct order of the threads. Yes, I am apparently insane. But, I love a fun challenge.
Have not heard back from the guy who *might* have a backup from *cough* 10 years ago when the most recent comment post was date stamped. I have a hunch that the dta table vanished around that time because the then super-admin has a comment on the front page about the site being broken and reaching out to the owner (but had not heard back). Further hunch is that the owner or someone updated the main site PHP Version and the oekaki site stopped working. I did not have any involvement with the oekaki at that time. It is just a few weeks ago that I decided to take a look and wondered if I could get it to be alive again... ("Oekaki-Stuff" *is* working 
)
Thank you for the SQL INSERT line of code. If I do try to restore by hand because a decent backup of the dta file is truly lost, then I may tweak that code to insert the record using the original postdate into the record instead of the current date/time.
If you are interested in seeing what the oekaki site looks like today, the link is here: oekaki dot pinkpt dot com
To see it "as-was", this is the WayBack, go to https://web.archive.org and search for pinkpt dot com / oekaki (I just updated the domain redirect about 2 weeks ago to put oekaki up front).
It does appear that the WayBack machine may have only archived the front page. If so, a true reconstruction may be impossible, but it looks like there is a lot there across the years that were archived. And the good news is, they archived some of the original jpgs.
If my understanding of the file/post numbering is correct... In the pictures folder, there are files numbered between 1497 and 1798, most with three flavors - full size, thumbnail(t) and reduced(r)?. If so, there are roughly 1496 pictures missing... I am not convinced I have the time or energy to rebuild that many posts and properly tie everything together. Sure, I can download any existing images from the WayBack, sort them out, copy/paste the original posts, etc. but each will need to be resized twice into additional files. Seems like a nightmare. But a fun one? Not sure if it is worth it for a site that has not worked for nearly 10 years.
But, I will say again that I am absolutely *thrilled* and truly thankful that your site is alive, monitored and you are super-responsive to my posts (and patient with me, too)!
Thanks again,
Blue
- Waccoon
- 01-28-2022 01:20:31
First off, I apologize for the forum being down for a couple days. My hosting service did a server update and I had to reset all my passwords.
The Wacintaki updater is pretty decent at scanning the table structure and updating as necessary, and I think all that's changed in the last decade is that a few fields have been added, but data does not need to be changed. The only major database update that ever happened involved the comment tables, to recode the tables from unencoded ASCII to UTF-8. The recoder utility was added in 1.5.6, and has probably already been done if the comment table has never been lost.
No image data is stored in the database. Really old versions of Wacintaki (and OekakiPoteto) would delete images in a cyclical manner to prevent too many images from piling up and wasting server space. The maximum number of images to store is set in the control panel. It's possible there are some orphan images or thumbnails lying around, because the original OekakiPoteto code was pretty awful and would sometimes delete things out of order. When I took over the project, it took a while, across several releases, to properly fix this stuff. If your board was originally an old version, it wouldn't surprise me if there's a bit of orphaned data that shouldn't be there.
The big issue you'll run into if you rebuild things manually is making sure the image types are correct. The field "ptype" must be a string of ("gif","png", or "jpg"). The thumbnail datatype is the "ttype" field, and is optional, so it may be (NULL, "gif", "png", "jpg"). Intermediate thumbnails are the "rtype" field, and this is also optional. If any field is NULL, Wacintaki will just ignore the thumbnails and use the full version of the picture.
The only key index is the "ID_2" field, which is of type SERIAL and is not important. The board sorts all rows by "postdate" instead.
The only truly important non-default fields are "PIC_ID", "usrname", and "ptype". "PIC_ID" must be an integer only, and the others are varchar/text. The username specified does not have to be in the main oekaki table, as guest posting is allowed. Everything else will have a proper default value if it is NULL or empty. The "datatype" field is for animation data only, and may default to "0". The default for the "postlock" field is "1" and should be left alone; setting it to "0" locks the thread.
If you're going to edit this stuff by hand, I recommend creating a new table from scratch, using your host's database tool to export an SQL text file, and then you can copy/paste the data. If the "postdate" fields are not unique, then the board will not sort threads predictably. Alternatively, you can create a SQL script and use the following template for each line, but of course make sure you've escaped all strings properly and know what you're doing:
Code:
INSERT INTO {$db_p}oekakidta SET usrname='{$name[]}', postdate=(NOW()+INTERVAL {$timer} HOUR), comment='{$comment[]}', PIC_ID='{$image[]}';- Blue
- 01-25-2022 15:33:59
Thanks Wacoon! That is pretty much what I figured after creating a few posts/sketches of my own to see where the data went in the tables. My only hope is that the prior caretaker of the entire domain has a decent .sql backup that contains the oekakidta table within. But, it would be really old. I have a sql backup from 2019 but the table is missing from that backup as well. My guess is that it vanished before I had access to the back-end of the entire site.
I think I can tie the original poster to the pictures that reside in the /pictures folder using the wayback machine, but it would be a painstakingly long effort.
Did the oekakidta table also contain the data of the sketches themselves (i.e. no file in the /pictures folder)? The apparent number of posts per person in the members table indicates that there are a LOT more drawings than what is in the /pictures folder.
If I manage to find an old copy of the oekakidta folder, I would like to pick your brain to see how I can manually update it from whatever version it is to 1.6.7. But, first things first. I must find it somehow, if it exists.
HUGE THANK YOU again for monitoring this BBS and responding so quickly!
~Blue
- Waccoon
- 01-25-2022 08:37:04
I'm afraid the oekakidta table is the main thread record for each picture, which includes all the picture information, datestamps, as well as the first comment made by the original artist. It's a big table and almost everything is in there. If the main table has been lost, there is no simple way to rebuild it, as Wacintaki does not have an API layer and this table also caches a lot of image information (size, datatype) and thumbnail info. There is no way to match a picture to its original artist.
The oekakicmt table is for all *additional* comments left by other board members, so it won't contain any hints as to which picture was drawn by which member.
- Blue
- 01-24-2022 19:58:54
Hoping this board is still monitored. I am trying to piece back together a really old Wacintaki Oekaki board that sat idle for a very long time.
As far as I can tell, it was broken years ago, possibly during an upgrade from 1.5.0 to 1.5.5. I was able to manually upgrade it to the latest 1.6.7 by carefully converting tables to UTF8 and adding/fixing tables in PhpMyAdmin. The cool thing is that I was able to make a couple quick sketches using the HTML5 editor! However, but the SQL database appears to have been missing the oekakidta table entirely prior to the upgrade. Not ideal because the existing pictures are "gone". They do exist in the pictures directory and there are comments for all of them in the oekakicmt table.
I think I have an idea of how the info is stored in the oekakidta and oekakicmt tables, but I have a couple of questions:
1. Was the oekakidta table added during one of the upgrades, splitting the oekakicmt file in the process? If so, what was the method so I can manually split them?
2. If not, is there a way to extract the needed info from the oekakicmt file to re-create the oekakidta file? At this point, I am not opposed to getting into the Wayback Machine to reconstruct the oekakidta table, but this is not preferred.
Looking at a few other posts that requested the log info, I checked the current logs and it says the old pictures are "WIP expire" which does not sound awesome.
Looking at the member pages, there are a LOT of missing pictures... Significantly more than what resides in the "Pictures" directory. No idea where they went, unless they were stored in one of the tables?
Yes, I am apparently a masochist. But, also a completionist, so I want to make this happen just for the satisfaction of doing it and having the living history available for the nostalgic.
Thanks!