SaranacLake

Sounds like you are talking about an eBook. Even if I just use a file(s), there wouldn't be bookmarking built in automatically, right? (Bookmarking is probably another reason some people get snobbish about eBooks.) What do you mean by "serialize"? 😕 At this point if I put my book into MySQL it would be because it allows me to more easily store, manage, and manipulate the book for myself as webmaster and for my customers. I have always been partial to database solutions, of course I wouldn't use MySQL if it didn't make good sense. On a side note, one of the challenges when you are creating something that you've never done before is that you just don't know until you've built things and then can see if they are a good or not so good design. But then that is why geeks like programming! 🙂

Wow, old-school diagram! (How did you get the spacing to work on the web?) Yes, that ERD is a start, although the columns you have under User shouldn't be there. So does that diagram imply that you'd favor putting my book in MySQL versus using files?

If the MEDIUMTEXT data type could handle up to 50 pages of text, then I could conceivably create a table like this... BOOK ********* - id - metadata fields - chapter_no - chapter_title - chapter_content - footnotes Then I could populate a page template in PHP with a given chapter at a time. Not sure if that makes sense - just researching the different ways to put my books online, and the pros and cons of each way.

Not claiming to be an expert in this area, but when I researched it in the past it isn't as easy as a lot of fiction writers made it sound (to create an eBook). Why? Because the things I produce rely heavily on the visual aspect of things versus just text on a page like some romance novel. My books are so large because I rely a lot on screenshots and graphics to communicate ideas about business and computers. Basically my books look more like college text books than some paperback novel. I'm sure there is a way to convert what I have to an eBook, but I think it would require me to do lots of research and reformat things as well. All of that will be v2.0 or later. But I will bow to others here and say that, yeah, I should probably offer a PDF version of my books along with the linine version so people have a greater sense of ownership in what they have bought, and so that they can read things offline, like on a plane trip. So you see no real benefit in storing my books in MySQL? If so, is that purely because you see no benefits of protecting my books from piracy, or are there other reasons? Not saying I won't just create HTML books and store them outside the web root, but I still wonder if there aren't other benefits of putting my books into MySQL including: - Everything is consolidated in one area - Ability to closely tie content and metadata - Ability to use SQL to pull up content - Possibly making it easier for users to search the book for certain text?

I guess normal people don't snuggle up with their computers to read a good book, eh? 😁 Sounds like pretty wise advice. So maybe I need to spend less time worrying about people stealing from me and more time just trying to sell things?

So I would be able to store up to 340 pages in a MEDIUMTEXT data type? If so, does taking that approach even make sense - to put one chapter in one column-row?

I'm going to be 70 when I finally "go live" with this website... 😞 Backing up for a moment... Does anyone here, see any value in having an "online" book, which would basically be a web page or a series of linked web pages making up a book? The main reason I came up with this format is because for a technical book, I think reading things on a computer as a web page is superior to a PDF or a black & white eBook with no graphics. (I have spoken with tons of people that can't imagine reading a book on anything other than a Kindle, but I think these people are the exception and likely fall into the trashy romance novel/fiction category.) PDFs aren't too bad to read, but like I said earlier, my fear is it is much easier to pirate a single PDF file versus a 1,000 page book which might be spread across many web pages. (And fwiw, @Psycho, there are ways to make it difficult to successfully PDF a web page if you want to be a jerk about it. I know for a fact because it has taken me forever figuring out how to do WYSIWYG captures from sites like the New York Times!) A lot of non-technical people I have spoken to on this topic basically have told me to "Get over piracy. Accept that it exists. And focus on making $$$ by creating useful content." What do you think about that topic? True. Fwiw, I don't want to make it "impossible" - just difficult enough that most people wouldn't bother. Let's work backwards... I wrote a 30 chapter 1,000 page IT/business book. It has lots of formatting for readability and lots of screenshots. Looks like most books you'd find in the computer section at Barnes & Noble. I soon realized that have one PHP web page that is 1,000 pages/screens long would be a problem - and enough to short out a mobile device!! 😁 So next I came up with the idea of have one PHP file be the book cover. The next PHP file being the Table of Contents (TOC). And then each chapter would be a separate PHP file, estimating each chapter is maybe 20-30 printed 8 1/2" x 11" pages. Each of these book components would be hyperlinked so it'd be like surfing the Internet in the 90s when it was still innocent and without any ads. To add to this, I figured I would do like I do for my articles now, and store the marked up chapters in MySQL and then serve them up to my PHP page template to create a finished product. That works for articles that are maybe 1-5 pages, but I'm not sure that there is a MySQL datatype that would hold 30 pages of HTML/content. And if not, then how do you logically break up that 30 pages of chapter text into record/columns? So maybe using the database doesn't makes sense... I guess if I followed @Psycho advice above, I could simply use my PHP page template to authenticate them and then load the content from a file located *outseide* of the web root. If I wanted to also offer a PDF, would I use a similar approach but instead of loading the PDF, maybe just provide a link to the file?

Long long ago (e.g. late 90s or earlier 2000s), PostgreSQL's advantage was that it had triggers, stored procedures, and cursors among other things. I still think PostgreSQL is more "enterprise" than MySQL, but I too am out of touch with it. As to your earlier comment, maybe this is an age thing, but I grew up learning on user forums like PHP Freaks where you can start a thread and have a (friendly) conversation with others. I don't consider StackExchange or Reddit or Quorum to be the same things - besides sites like StackExchange seem to be *antagonistic* at best?! If you know of any user forums that are active as this site but dealing with PostgreSQL, please do tell. I searched on "PostgreSQL forums" last night, and the only one that I saw which wasn't vacant, had a few posts this year, then all the rest from 2018 and before. (Um, there are dozens of new threads on PHPFreaks each day!) Sounds like MySQL is probably where I should focus for now, but I'm open to other suggestions. Thanks to everyone here for the help either way! 🙂

Funny you should mention PostgreSQL... Back in the day, PostgreSQL was light-years ahead of MySQL on really the only "enterprise" open-source database. Then in the early 2000s MySQL lessened the gap. I have been tempted to go with PostgreSQL, but my fear is that there doesn't seem to be any place to get active support. I can come to sites like PHPFreaks - one of the remaining active forums on the Internet - and get some help with MySQL, but what do i do when I need help with PostgreSQL? And what would be the benefits of going with PostgreSQL considering it have less users and less support? Like your idea but those are my concerns...

True. *sigh* You are not the first person to say this to me!!! Okay, so help me to help you are a potential customer... Offering eBooks is off of the table for the foreseeable future, because it requires me to learn quite a bit about creating eBooks plus it would require me to have to basically completely rewrite my book so the formatting works in that format. I could offer PDF's in addition to my "online" books, because it would indeed give customers more of a sense of ownership, but I'd still likel to do all I can to lower the chances of piracy. Any suggestions from either a business standpoint or a technical standpoint of how I could accomplish this and still allow people like you to have a copy of the book you bought with you? What I was thinking of doing is breaking my book up into chapters where each one would be a file. So I guess we are talking about a similar approach. On a side note, is there any benefit to putting my book into MySQL? Even from a data management standpoint? If so, what would be the best approach to take? One of my books is nearly 1,000 pages long with tons of screenshots. Not sure how to put that into MySQL in a practical way? A chapter would be between 20-40 pages with images. Not sure if there is a datatype to handle that?

Ouch! 😛 Okay. Good catch!!! Yes, I missed that fact! In my proposal above, all I would be re-populating would be the username and email. The password and cc details fields would not appear until AFTER the form re-loads after the email was sent. As I said in my last post that you didn't completely read, I think @kicken and @cyberRobot (and you) are right in that maybe it is better to confirm the email after I get their money. However, to my point, if the user provides a bogus email or cannot type, then I will make it difficult for them to fix things. Not to be a jerk, but to ensure the person registering and paying is the same person talking to me via email. I'm sure some people would find the policy I proposed to be too draconian, but it seems like the only reasonable way to address those exceptions. Feel free to suggest a better way! 🙂

Valid point, but it is much easier to download and share a PDF - which is a single file - versus a webpage with stylesheets and remote images and so on. But, yes, anything you see can ultimately be stolen. *sigh* I don't disagree, but when I started this thread I was thinking more from the standpoint that maybe it is easier to navigate to webpages that you shouldn't have access to than to something stored in a database. Since I always assumed that I would store my book in the database, I wasn't prepared on how to do it as a file. So how exactly would I want to go about presenting a book that only paid users could see? If I didn't use the database, I guess here is the approach iwould take... - Take my formatted book from LibreOffice and convert it to a web page, or series of web pages, using HTML/CSS/etc. - Embed that HTML inside a .php page. - At the top of my script, have a function that compares the user's user_id against an entitlement table to see if they have access to the book. - If yes, display the book/page. - If not, display a message stating they need to purchase access. Is that secure enough, or are there other measures that I could take to prevent unauthorized access? Yes, that was probably more of my concern in this thread. A-ha! That is what I needed to hear. See, when my content was in the database, then I didn't have to worry about people accidentally navigating to it, and thus why I thought it was maybe more secure? So I have an "outside-web-root" directory, and you are saying that I'd simply put my books there? So do you just accept that fact, and move on? Am I being too paranoid about people stealing my books and guides? Also, would there be any benefits to storing books/guides in MySQL? (I am dong it now for articles, and it seems so much easier to manage hundreds or thousands of articles in the database then a series of loose files!)

Are you saying that the difference between MariaDB and MySQL is negligible? If so, why did MariaDB fork off other than because of maybe open-source purists? If you were me would you stick with using MySQL for my business or switch to MariaDB?

I've heard lots of conflicting things about open-source database over the last couple of years, and am curious what everyone here thinks?! First off, there are lots of people saying that using MySQL is dangerous because Oracle now owns it and it may become a paid-to-use application. Other say this is FUD. Then there is MariaDB. The fact that the creator of MySQL forking off to create MariaDB says a lot. So why would a person want to use one versus the other? It seems like most webhosts still offer MySQL. And I think there is slightly better support for MySQL vs MariaDB, although it seems like most user forums on the Internet are gone - short of ones like this. I am building an ecommerce site and startup business, and I do NOT want to get into a situation where I get stuck with licensing costs or other issues due to some mega corporation trying to extract $$$ out of me! Finally there is the technical issue of which database is better? Any thoughts on all of this?

Let's see if I can remember what I formulated last night... Step 1: Review Cart Step 2: Enter Account Details Username: ______________ Email: _________________ **Note: Make sure this email is valid, because you will need to respond to the activation email in order to use this account. Password: ______________ Confirm Password: _________________ Step 3: Enter Payment Details And son on.... << Process Order>> When the form is submitted... - The data above in inserted into the database. - Payment details are sent to the processor. - An activation email is sent to the email listed above. - Money goes into my bank account! 🙂 As stated, in order to start using the account, the user will need to click on a link in the activation email. They will be prompted to do so at log in if this hasn't been done, and cannot use their account until it is done. If the user never received the email, I could resend it. If the user used a bogus email, then they would need to call me. At that time I would require them to create a new account using a valid email and pay a 2nd time, and after they activated the new account, I would credit them for the first charge and close out the bogus account. If they contested this, I would refund their money, however there wouldn't be a chargeback since they have to accept my TOS in the checkout and I will spell out that lying is no grounds for a chargeback. If the user made a type-o in their email, I would require the same process as above. This may seem harsh, but people need to follow rules and use common-sense. And I want the account creation, validation and payment to happen on one transaction to protect myself and the customer. I could allow the user to log in with a bogus email and charge it and then resend the code, but that is too much extra logic to have to add to accommodate dumb asses!! I *think* this applies the wisdom that @kicken and @cyberRobot provided above, but let me know your thoughts!

Thanks to everyone for their ideas. I think @kicken brought up some great points, and I'm sure there is a way to "have my cake and eat it too", we just aren't quite there yet... But this is *exactly* the kind of mental exercise that I needed help with, so thanks everyone!! 👍

I have to kick your idea around, but I have to say that your idea is looking better than mine! 🏆 The idea about the 3-7 days thing is very interesting... Yeah, that is a bit trickier and I definitely have to think about that one. Scenario #1: Phat-fingered registration email In this case, the customer doesn't get the activation email. And to make matters even more complicated, your email and password are how you log in. So if a customer phat-fingers their email (e.g. "kikken@gmail.com") then when he/she goes to log in as "kicken@gmail.com" they won't be able to log in?! And if they then send me an email explaining, I'm not going to trust that. So now what do I do? Do I have to call them at their billing tele #? Even there, how do I know that I am speaking to "Kicken" and not you kid brother/sister?? See the problem? Scenario #2: Entered fake email Here, the person might be able to successfully log in as "screw_you@gmail.com", but since they didn't get the email, now I have to allow them to change their email to something legitimate. I guess (??) because that fake email was used when they they log in after registration, that I can assume it is the same person who paid by credit card, but that sorta makes me nervous... And if they made up a fake email and cannot remember it, then you have the same issues as scenario #1. See what I am saying?? There is no "silver bullet" in any design. My way has pros with security, but your way has pros with closing the deal. I think we are getting closer to a solution, but I think it needs to be tweaked to address your concerns and my concerns. Actually that is horrible for security since all of these sites get hacked!! Plus I think Facebook/Twitter/Google are scum.... 😉

Not sure what DL is. I decided on having online books for now because I am too paranoid about piracy of PDFs and eBooks, and print books are not profitable. When a person purchases an online book from me, they will be given access to that online book via my website each time they log in. I'm sure some people might try sharing their credentials with friends, but I have ways to identify that and take action as necessary. I am not offer refunds, so once people buy the book, they own it. Not sure I follow what that accomplishes? The way I have things designed, you can either buy a subscription and then get access to to all articles via your account. In addition, you can buy an online book, and you are buying access to that single book in perpetuity. But to read the book, you'll have to log in each time. Just like you'd have to log in to read some other premium content on another website. I just wasn't sure how hard/easy it might be for someone to circumvent the log in process. If I have a book as a file out on my webserver, I am afraid that there may be lots of ways to get to that article and bypass my website and logging in. i was thinking that if the book is served up from MySQL, then that might be harder to get to, because you would definitely have to be logged in and have access to the book in the database in order to view it. Make sense?

Yeah, but I figured it would be harder to hack the database than my php script. I dunno - just trying to be secure. How so? My website sells content including articles, books and guides. The books and guides are online content that you would access by logging in to the website after you pay for them. No eBooks or PDFs at this time. Articles on my website are already database driven. I always assumed that I would do the same for books and guides and am getting ready to code that part of my website. But in preparing to do so, it occurred to me that trying to serve up a 600 page book from a database is NOT the same as serving up a 5 page article! For articles, I have a PHP page which serves as a page template and then populate the actual article by grabbing it from the database. The article itself has already been marked up in HTML so it is plug and play. I guess I could break up my book by chapters, but I'm not sure if a 30-40 page chapter would fit into a MySQL record.

Hi. I am working on a website that sells online subscriptions to premium content. On the low end this includes articles, and on the high end guides and books. In the back of my mind I had always planned on putting this content into MySQL for safe keeping, but in the last day or so it has occurred to me that putting an entire book into MySQL could be cumbersome at best?! Which leads to this question... Can you easily protect a PHP page from unauthorized users and outsiders? My original desire to put things in MySQL was driven much more by security than any of the more obvious reasons you'd use a database. I will be putting articles into MySQL, but the more I think about it, trying to put a 500 or 1,000 page book into MySQL could be difficult at best. For articles, I simple have a PHP page that loads up the article from MySQL and first checks that the logged in user has the proper access rights - meaning they are a paid subscriber - before allowing the article to load. I could do that with a guide or book, but the question becomes, "How do you put even 500 pages into a database table and easily access it?" What do you think?

Well, PHPFreaks doesn't make you paste a code, but when you create an account you do receive an activation email where you have to click on a link to activate your account before you can log in. Understood, except that doesn't help for people like me who type their email in the first field, do ctrl+A, then ctrl+C, then ctrl+V in the second field, ensuring that I have two *wrong* emails!! 😋 Doing what I described above would help me as the website operator. If I implement it as described, is it that big of a deal to people buying a subscription? Right.

I agree when I am buying a product. But if someone is buying *access* to a website, then people must understand that requires an account - and thus registration - plus it sorta follows that the company needs to make sure it has a valid email and payment details. I could validate the email address after I take payment, but it just seems easier to do things all at once. (I personally find it more annoying when I go though some process only to find out that there are still MORE forms to fill out?!) 🙄 If you want to buy music or apps from Apple, you *must* have a valid email and payment details before they give you access. And before I could post on PHPFreaks, I had to validate my email address - thank God it is free here! My website will have LOTS of *free* content, but like many sites with exclusive news and articles and with expert advice and analysis, if you want access to THAT information, then you will need to create an account, validate your email address, and pay $40 for a one-year subscription to my website. If you aren't ready to pay, then surf the free content of my site with no account required. I am hoping that is a very *reasonable* business proposition... 🙂

I agree with you, but you didn't read what I am trying to do... 😉 IF I was selling physical products, I agree 100% that having a "Guest Checkout" - requiring no account sign up - is crucial. BUT, to be clear, I am selling a *subscription* to my websites and the premium content which you can only get with a paid membership. The easiest way to understand is to think of an online newspaper/magazine like Fortune or the Wall Street Journal. Companies like this may offer some free content so people can get comfortable with what they have to offer, but especially with the WSJ in modern times, unless you get a paid subscription, you basically cannot access any of their online newspaper. That being said... If you are buying a subscription to an online newspaper/magazine, then it follows that you'd need an account, right? All I'm making people do is help me to verify - one time - that I have your valid, working email address when you create your account, because if you give a bigus email or phat-finger your email address, then it create a real PITA for me afterwards, PLUS then *I* would be suspicious if I had a paid account and some random person is emailing me saying, "I am the real Kicken, so please give me access to Kicken's account and account details." See the issue? Okay, that is a valid argument. As described above, a user must have an account to access premium content via their paid subscription. And since I am dealing with an account and money, obviously a valid email is also important. (You can't set up an AppleID or buy things off of Apple app store without a valid email and credit card on file, right?) Thanks for the code. However, since I don't know JavaScript and would like to better learn it before using it, I was hoping to do the same thing using PHP... I outlined the flow above in my last post, but to be clear... The user would choose a subscription plan by clicking on a "Select" (or "Checkout") button and checkout.php would load with a form just displaying this... Checkout Page Username: ________________ Email Address: _______________ <<Send "Security Code" to my email>> (button) When they click that button, I would... - Save the Username and Email to the $_SESSION - Generate a Security Code - INSERT the Username, Email, and Security Code into the Member table - Email the Security Code - Reload Checkout.php displaying the prepopulated Username and Email fields, PLUS all of the other fields (e.g. Password, Credit Card details, etc.) When the user clicks "Process Order", I would... - Run an UPDATE query to store the hashed password, user's name, billing address, telephone # into the Member record. - The credit card details would be sent to the payment process. - The order processed. - A confirmation page displays and confirmation email sent. So by my calculations, I could do everything I need using just PHP - although for v2.0 using JavaScript would be more efficient. Follow me?

That's good I understand your concern, but felt my solution was pretty unobtrusive. Let me explain again to make sure you follow me... Use-case ************** - User chooses a subscription plan (one click) - System presents checkout page - The very first field asks for the user's email address. - Below that is a button labeled "Send 'security code' to my email" - System sends user an email with the code - System creates a record in database including the user's email - User checks e-mail - User pastes the 'security code' into the second field on the form - User completes remaining fields (e.g. credit card #, billing address, etc) - User clicks "Submit order" That above process is no different from any other checkout process online - and probably a lot shorter than most - other than I do ask the user to take two additional steps... 1.) Click a button 2.) Past a code from your email into the form Do you really think anyone would protest to something so simple? I understand that I could take their money and then later on ask them to validate their email before they log in, but in my humble opinion the above process is easier on everyone, but you can of course disagree! 🙂

Well, as mentioned above, the plan on checkout was to immediately ask for an email and then have a button labeled "Send security code to my email" and when/IF they click on that button, then I send an email with the security code PLUS I create a record in the database, so at that point I could track the cart abandonment. Of course, if they don't make it past that first field and clicking on that button, then I don't have a way to track cart abandonment unless I used JavaScript which is the whole reason I am trying to do things like described above! 😁 Valid points, however, if you are joining a paid membership site to get access to premium content and you have to pay with a credit card and you don't trust the website owner, then you've got issues?! I think most people expect to have to give out a valid email address during an ecommerce transaction. I just want to be doubly sure their email address is valid and not phat-fingered because that is how they log in and how I sending billing details, receipts, password resets, and so on. Even this website requires a valid email except that it requires that you validate the email in more steps that the experts say it should take. So I'm not trying to do anything that isn't being done here. The idea is that you enter your email, click a button check your email, copy&paste the code and you can proceed checking out. (In theory that would take an extra 30-60 seconds.) It might be a pain, but it is for everyone's benefit. If you phat-fingered your email, you wouldn't get admin emails and I wouldn't know and you wouldn't know that any time soon. Then we'd have to figure that out, and I'd have to go in and update your database record. PLUS, if you contacted me after the fact, how could I be entirely sure that you are the customer and not a hacker trying to hijack the customer's account? There is a security factor in requiring email verification and payment all in one shot.