Heh heh heh..... (@ myself)Originally Posted by yamangman
I hadn't even noticed that. Yes... Password usually required!
Heh heh heh..... (@ myself)Originally Posted by yamangman
I hadn't even noticed that. Yes... Password usually required!
Haha, ok, so password field needed. What field options will i need for that?
Furthermore, if you intend on using session variables, I suggest another field such as user_type, which would contain various user levels. You could then set access rights on each page of your site for each user type.
To err is human. To really foul things up ... you need a computer.
lol, this is going to get slightly more advanced than i thought
doh, i've just remembered, i'm putting a photoblog in there as well lol. I want to be able to browse all the photos in the different categories that they're in. What would I need to do that (database wise)
You're designing without a stable set of requirements. You need to go back a level and define your requirements first before you start coming up with an E-R diagram.
That was the only one i forgot, everything else is to specification.Originally Posted by Az
*bump* any ideas anyone?
You'll learn more if you try yourself and we'll point out any errors or improvements. I'm sure you can at least make an initial stab at it, after all as you've said you already have a stable sepcification so it should be a simple matter to work out what fields will be required. If you can't then your spec needs to be improved.
Also, there's no need to bump a post if only 6 hours has passed by, most people will be working and may not have access to the forums, at least give them 24 hours to respond
roger that boss, i'll get to work on the SQL code
Well grouping photos is not really any different to your existing item / item_type arrangement... Though it would be better with groups as well (i.e. an item_type of photo and then a group of photos under the heading "Photos from holiday, August '04"... As for actually storing the photos you COULD do it in the database via a blob but I wouldn't recommend it. Instead you should store the file name / path and that will be included in the final output (i.e. the HTML). You could do the same thing for your other entries though there's no need to... I think keeping the data in the database is better for your non photo items. If you were going to do it that way (all external files) then SSIs (Server Side Includes) would be a better way of doing it for the blogs / articles.
Yup, i had this approach for downloadable files once. I was thinking of doing it another way. Use the PHP to check the folders (each folder would be a different category of photo) and then display all the folders, click on the links which would take you into the folder and preview each photo one at a time. That way it would require no database work, just PHP work and all i'd have to do is upload the photos into the necessary folders. How about that for an idea?Originally Posted by malfunction
Depends on if you want to be able to 'auto publish' any file in the directory as soon as you upload it
Yup, i would publish any photo in that directory, well that's ok then i can just lob that particular code in the database under the content category instead of including it in the switch, would be easier that way.
You will need to check that the file has been completely uploaded in the PHP then - so you dont give red Xs to anyone viewing
I'll do that when i get on to writing the script. Now i need to concentrate on the database code to create the tables. Only problem is, i don't know how to do joins in SQL lol. Right, time to get on it! I'll paste code here when there's progress
There are currently 1 users browsing this thread. (0 members and 1 guests)