I work the same way sometimes. First, I'll just figure out the quickest way to Get The Job Done. Then, I'll work backwards from there to make it clean and elegant.

Hit a slight snag: Shouldn't entryid in journal_entries be auto_increment? Otherwise it seems to me that we would have to find the highest entryid in use before being able to insert a new one.

Having entry_id auto_increment shouldn't interfere with the ability to show the entry number in the journal since that can come from a simple count.

Re: your comment about "clean and elegant"
That will be your department. I'm just hoping to have something that works for you to magically transform. So far it just crudely regurgitates the sample stuffed into my db. You can see by the above that I haven't figured a way around not having entryid auto_increment.

Good call! Yes, of course it's got to be an auto_increment field. I've adjusted the first post in this thread.

The add_entry is becoming the most complex part. It's already more than double the size of any other part and I still don't have it ready to actually insert data into the database.

Do you want to see this stuff as it grows or wait until everything works or what?

Another thing, which I may have asked you before, concerns the uploaded photos. Should we have a field in the journal_photos table to preserve the name the user gives the file? That name can't be trusted for actually storing the file, but it could be useful as a caption or "alt" or some other way in the user's journal. It just doesn't seem right to toss that data, just as it wouldn't seem right to toss part of the entry text.

My take is that the user's filename will be useless most of the time. For example, a situation where the file will be named "56 chevy underside.jpg" is probably not going to be very common. I ran into this situation with the photo album. I had thought we could use the filename as keyword-dense text. No such luck, in most situations.

I had thought we could use the journal entry title name as the alt text for each photo in an entry.

Yes, let me check out what you've got as it grows. Post in this thread.

My umpteenth re-write is a bunch of small files (13 files, 12,642 bytes so far). Want it as a tarball or in CODE tags in a message?

You said "/journal_photo_directory/userid/journalid/photoid.type". Will those directories be created when the user starts a journal? It would seem to me that the best way is to create them when the journal is created or else we'll have to test for their existence and mkdir if !exist with each photo upload.

It looks like journal_photoid also needs to be AUTO_INCREMENT.

I haven't yet figured out a way to avoid duplicate entries. If you submit the same entry twice it will happily insert it again with a new entryid. Likewise for the photos, which is bad news for the directory and disk.

I spent the whole day beating up on this thing to get uploads and inserts to work. (I've never had to deal with uploads before). The end result is add_entry.php and add_entry_db.php are monstrous and convoluted compared to everything else. It desperately needs simplification via functions or that object-oriented majick.

'tgz' doesn't appear to be a valid file extension, so I can either zip 'em up or post within CODE tags, maybe 1 file per post.

You're getting behind in the conversation, Jon.

Tried to attach the zip, but it's 279.2 KB.

2nd try...

WARNING: the attached zip contains horrible alpha code. Do NOT let it near any database you depend on. It has been tested by 1 user on 1 disposable computer running mysql with a database nobody would care about. Think of the people who jumped off cliffs with feathers glued to their arms before airplanes were developed and you'll get the idea.

Attached Files

journals.zip (279.2 KB, 1 views)

Upload it to this thread as an attachment. I've just added gz and tgz files, and upped the limit for zip files.

Yes, we can create the directories when the user starts a journal.

We don't need two auto_increment fields in the same table, it's redundant. We could just have the journal_photoid filename the same as the journalid, plus a prefix. And, we could store the filetype of the main journal_photo in an ENUM field. So, we would remove the journal_photoid column, and in its place, add another ENUM('jpg','gif','png') column. We could prefix the main journal photo with "main_" or something like that, and stick it in the same directory as the rest of the journal photos pertaining to that journalid. So, if the journalid was '123', then the main journal photo filename would be 'main_123.jpg' or 'main_123.gif' or 'main_123.png'. What do you think about that?



I'll think about this. I'm sure there's a way to handle this with PHP.