Leaderboard

Your plan is fine. Just to throw this out in general, but over 50% of web traffic is now done with a mobile device. I would urge you do some research into responsive design. These days, you want to start with your mobile design and build it up for larger viewports, vs the old days when you started with your primary design and figured out how to scale it down. It's concentrated into css, with the exception of the newer picture element supported by most browsers. Layout is also important. Let's say that you have a layout where you have a picture and next to it a column of text talking about the image. On a mobile device you are going to move that all to 1 column, and will need the descriptive text to go underneath the image. You want to learn grid or flexbox (grid is the current state of the art). Images on mobile is a complicated subject, due to technology like retina. You can't just generate a scaled down version for mobile devices and serve that on a retina device, unless you don't care that the image may become illegible. Any illustrations would be best off rendered in svg, and in fact everything you can render in svg is ideal, because it intrinsically will scale up and down whereas any raster format images won't. Again for the raster images, this is where the html picture element is helpful. I hope that you are not using the web publishing model because you had concerns about "piracy" or content sharing. Having your content in a subscription website won't prevent privacy. Every browser has built in capability to save html, print, and print to pdf.

Don't be afraid of having to re-factor things in the future. You don't have to get the perfect layout from the get go. I find that many times even when I tried to plan for the future and design accordingly I'd usually miss something and end up doing some refactoring anyway. Best to just wait until you know what you need rather than guess at what you think you'll need. The book/component table structure sounds fine. If in the future you decide to split it up further you can. If in the future you decide to do pages/sections you could probably do so with relatively little changes to the tables.

Aka, poor implementation. No JS is necessary to avoid loading the full sized version, you just link it separately. <a href="full-size.png"><img src="thumb.png"></a> I personally wouldn't, no. I have a dual-screen desktop so I'd open the book on one screen and Photoshop on the other. In the particular case of Photoshop it seems unlikely in general anyway to me. The person would need a desktop to run Photoshop on anyway so if they were trying to follow along and learn why not just open it in a browser on the desktop. Right, but if you're loading appropriately sized images then 30 images loading shouldn't really be a big deal. A full-size 1920x1080 scaled down to roughly phone-screen sized images should only be around 20-100k in size. 100k * 30 = ~3MB. 3MB on an average mobile connection would take all of 1 second to download. It's basically illegible sure, but that's where the previous point of having mobile-friendly versions comes in. Alternatively, link the illegible version to a full-sized version they can load and zoom/pan around on demand. A lot of people do things on mobile now, so it's certainly worth considering that market, but in my experience people still acknowledge when something isn't really a good fit for mobile and will move to a desktop/tablet in those scenarios (if possible). I have a friend that does practically everything from her phone mainly because for a long time she had nothing else. From time to time however she will come by to use my computer for things because they are just not mobile-friendly tasks and she recognizes that. Most people I know are still rational about what is and isn't a good fit for mobile, so I think your fear of everyone demanding a refund because your site isn't 100% mobile friendly is irrational. Sure, there may be some because people can be dicks but that's part of business. If your books deal with teaching software and that software is primarily a desktop thing I'd wager most people will interact with the site from a desktop. I'd make some considerations for mobile (responsive layout, smaller images) for those who might want to read some on their phone while away from a desktop (ie, commuting) but wouldn't spend a ton of time up front trying to make that experience perfect. I'd push that until later when everything else is up and running and more time is available to focus on that and/or real customers start requesting it.

I'm guessing when you changed to POST you did not change the array to $_POST which is why it didn't work.