Furry stuff, oekaki stuff, and other stuff.
You are not logged in.
I have a Wacintaki site with 6 studios, which share the same user database. Three of the studios are set up for different levels of drawing (quick sketch, more involved drawing and serious drawing). The other three are special purpose studios (Jams, Uploads from other sites and Constructive Criticism).
The thing that is most requested from our members is that they would like to be able to save the draw to a different studio than the one they started in, if it warrants it. Like, say I started a quick sketch in Studio 1, but it turned into quite a lengthy draw and I'd like to save it in Studio 2 or 3 instead.
Can you see any possibility of something like this in the future?
Thanks,
Nullig
Offline
This would require a major code rewrite, and a change to how the pictures are stored in the sql database. It is possible, but you would have to rebuild the boards from the ground up with multiple boards as the main idea. I think wacoon has has it planned for the future, but no date to actually do the recode yet =P
Offline
Yeah, there's a number of issues with switching pictures between boards, because you have to move files from folder to folder, or have all the boards share one pictures folder, and that's where things get really messy. I don't want to go there without some clean code. Passing comments back and forth in a forum is a heck of a lot easier than moving pictures around the filesystem and dealing with tons of permission issues that vary from server to server. Making code is easy. Making it redistributable and compatible with multiple server types is not.
One of the big issues is installing such a system in the first place. I'm not sure if it's better to have each board in its own folder and simply declare a "master" pictures folder outside the main path, or have everything run out of one folder and use breadcrumbs (like what usually happens in an image gallery). In the first case, it's easy to make clean URLs, but installation is more difficult. In the second case, installation is easy, but the URLs can be messy, and I can't depend on URL rewriting because that feature isn't available on most free servers.
Multiple board support is one of the few things keeping me from starting a new code base, actually. In theory it should be easy, but the way that servers are set up, and the large number of differences between server configurations actually makes designing the board tricky. Custom root paths are a start, but that can be a security risk if the person installing the board isn't totally sure what he/she is doing when installing the board.
Offline
You *could* select how many boards you currently have like a menu like:
How many boards do you have? [textarea]number[/textarea] where number can be 1-xxx
Please enter the path to the boards: (based on number above)
[textarea]Path to board 1[/textarea]
[textarea]Path to board 2[/textarea]
[textarea]Path to board 3[/textarea]
[textarea]Path to board 4[/textarea]
[textarea]Path to board 5[/textarea]
When making the sql comment, just have it reference that board
INSERT INTO database WHERE boardname='board'
when displaying pictures
SELECT * FROM database WHERE boardname='board'
When moving pictures
UPDATE * FROM database WHERE picture_id='pid' AND boardname='board'
Granted, that's a dumbed down version, but if you're going to be restructuring the code anyway, you might as well make it work with the maximum compatibility possible.
Also, if you were ever to update a boards name/path you could easily change it in a similar manner like
UPDATE * FROM database WHERE boardname='board'
->
boardname='newboard'
Last edited by Ashass (07-09-2008 13:21:40)
Offline
Yes, with an extra field in the oekakidta table for the board id, you wouldn't need to separate the pictures or data at all. You could use the board id field to separate the display of draws according to the board and it would be easy to move pictures around with a simple utility.
I know it would require a lot of recoding of the sql statements...
Nullig
Offline
That's the easy part. The hard part is rewriting all the interfaces so your board marker doesn't get lost. This includes administration, searching, posting new pictures, and the like.
Rewriting all the interfaces is effectively re-writing the whole board, but without all the database and template layers that really need to be implemented.
Offline