I'm going to be rich. For mental anguish, suffering, induced paranoia and trauma, my lawyers will get in line with all the others going after Jon's mountains of gold.
(Ok, this is barely on-topic for this forum, but I have to squawk about it somewhere. Also, it's about what will hopefully become the basis of the new journal software and so any suggestions or help from Hotrodders.com members should come out here.)
I broke everything about 'journals_test' (http://www.crankshaftcoalition.com/f...&page=11&pp=10
) while trying to eliminate places where SQL injection attacks could take place. Jon is the one who mentioned such attacks and is thus responsible for my paranoia and suffering resulting from a Google search to find out how those happen. It's amazing how many trivial ways attackers can take over databases through "web apps".
The latest breakage took a marathon of head-banging to fix. My idiotic, Frankensteinian mess kept naming all uploaded photos by the journal ID, saving them in the wrong place, not updating the photos table in the database, and being smug about it by not reporting any error at all. After a day, 2 all-nighters, and creating 32 broken or empty test journals, it remains smug, but functions as it should. (The worst was caused by the differences between MySQL's LAST_INSERT_ID and PostgreSQL's currval('[sequence name]').)
Things that are working:
- multiple journals per user
- a summary entry for each journal, with 1 photo
- a table of contents per journal, with thumbnails
- 0 to 6 photos per entry, with thumbnails
- paging of journal summaries
- sorting by journalid, userid, date, entries, views, etc.
Things still broken:
-- adding an entry
-- editing an entry
-- formatting user input
As soon as those work again, I'll upload the whole mess to the Crankshaft Coalition thread linked above. A limited test of it will then be set up on my own website.
Feedback and help are welcome.
Back to breaking things...