5 ms·
Show HN: BlogFile; ~3000 line, single file PHP blog software
- drivebyacct2 14y agoThis is scary. All in one file. PHP. CSS/HTML/PHP all in one file. I don't mean to be a jerk, but what problem does this solve, or was it simply a personal challenge/adventure? edit: Some of this is answered on the GitHub page. I guess I'm going to be concerned if someone is worried about how to unzip a file on a server...
- samuellevy 14y agoMostly a personal challenge. I was also sick of things being over-bloated. I wanted to see what I could get away with in a single file without things getting too large to manage. It's getting close to unmanageable now, but I think it's still OK.
- drivebyacct2 14y agoI don't mean to be a jerk, but multiple files does not mean bloat. In fact, shoving a bunch of orthogonal functionality into a single file screams bloat more than 3 thousand-line files, or 6 500-line files.
- Produce 14y agoAlso not meaning to be a jerk, but that file has a thousand line switch statement. For the love of all that is holy, won't someone think of the children?!
- samuellevy 14y agoHey, at least I'm not using GOTOs. In due course, I'll probably re-write large parts of it, and make it more... "clean", but this really was a quick project hacked out in my spare time over a couple of weeks.
- samuellevy 14y agoSorry, the "bloat" and the "single file" were different goals. I'm sorry if that wasn't clear. That being said, the fact that it was in a single file meant that I was more concious of the size, and contributed to me cutting out my own bloat/planned and unnecessary features. This isn't meant to be the pinnacle of design here; just a fun exercise which incidentally made my life easier to manage (I'm sick of using Drupal for blogs, and getting constant spam posts and user notifications from wordpress. I also don't use most of the features from either of them, so this has provided me with just the features I want).
- cfinke 14y agoIt's an interesting exercise, although the first downside I noticed of the "one file" mantra is that all of the CSS is served inline in every response. Also, you may want to consider handling MySQL errors in a manner other than just printing it to screen along with the query. At the very least, log them somewhere where you'll be alerted of the error. As a user, seeing "MySQLi Error: [...]" doesn't help me or you. It'll be interesting to see if you continue the project and how far you take its functionality. Some of my co-workers were just today discussing the tendency to want to rewrite a system from scratch in order to simplify it and avoid any problems with backwards compatibility, only to slowly find yourself rewriting the "unnecessary" features from which you were trying to escape.
- samuellevy 14y agoThe CSS isn't actually that large. The entire home page (CSS included) is about 4-5KB. The analytics code from google is three times the size of the rest of my page. What MySQL error did you run in to? You're right that I should probably hide & log them, but at this stage logging is a low priority. I'll add it in later on. This is built largely for personal use, so I'll only implement features that I feel I actually need, and even then they may not all make it into the main code base.
- cfinke 14y agoI didn't encounter any errors; my comments were just from browsing the source.
- lostsock 14y agoThe CSS doesn't have to be inline. You can use a regular HTML stylesheet link with the SRC looping back to the same index.php file with a different GET value and a CSS header that serves the CSS. http://phpfm.sourceforge.net/ http://phpfm.sourceforge.net/ does something similar (A file manager in a single file)
- quadhome 14y agoOther micro (as in code size) blogs: * Blosxom http://www.blosxom.com/ http://www.blosxom.com/ (440 lines) * Trivium https://github.com/chneukirchen/trivium/ https://github.com/chneukirchen/trivium/ (172-ish lines) * werc http://werc.cat-v.org/ http://werc.cat-v.org/ (more like a micro-meta-CMS)
- cheald 14y agoYour brute-force protection is: a) bypassable (by simply not sending a session cookie), and b) exploitable to DOS your server (PHP processes are single-threaded so sleep() is basically just a blocking call) - I could just bombard your server with a bunch of login requests to eat up all of the connection slots that end up sleeping for a very long time. You can't serve legit traffic when all of your PHP workers are off sleeping for six hours.
- samuellevy 14y agoYeah, that's pretty fair. It's little more than protection against automated scripts which scrape the net looking for easy ways in (as is my comment spam protection). There's not a huge amount to be gained by building a super sophisticated anti-spam or anti-brute-force system until it's likely that someone will actually write an attack specifically for this software, and seeing as I built it mostly for my own use, anyone who did that is probably just trying to do damage to me (for whatever reason).
- cheald 14y agoI'd at least take the sleep() out. That way, you get rid of the super easy DoS vector. If someone were to deploy this on their shared webhosting, they'd find themselves with a very upset host. You're using the very fast md5/sha1 (why both?) functions for password hashing. PHP has bcrypt support; why not use it instead? That a) accomplishes the goal of making brute-force untenable, and b) further protects your users' passwords in case you ever accidentally introduce a SQL injection (which, if you continue to work on this project, you probably eventually will; no personal offense - that's a big part of why more comprehensive frameworks that try to abstract away from raw SQL exist. Human make mistakes, especially in 6000-line superfiles ;) Edit: Also, your password updates (and other POST-ish operations, except commenting) don't have any kind of CSRF protection, so I could reset your password if I can get you to interact with a page where I've set up some "proof of concept" of something you might find interesting, with a form to post to yoursite.com/?p=savesettings&password=0wned, at which point I just log in and take admin control of the site. Since you don't ask for a username on login, such an attack would be extremely trivial. (As another commenter mentioned, it's easy to discover that much of the 'bloat' is actually stuff you want!)