requinix

I really don't know. phptherightway.com is the most reliable place for good PHP advice, but they don't have anything for MVC. Typically one discovers that after the fact... Perhaps the right thing to do would be to pick up a framework like Laravel. Or Symfony. They do all the heavy lifting. If you spend some time working with them, not only do you get to learn about them (a good idea) you'll understand more of how stuff like MVC and a variety of other things work.

That's stupid. Line limits are arbitrary. I mean, a basic PHP class without any code takes about 10 lines already. A good class takes as many lines of code as it needs and no more. There's MVC the principle and MVC the architecture. For the moment you want MVC the principle. It's about separating models (database and the code that handles data on its own right) from view (presentation and output) from controllers (logic primarily to connect models with views). It helps you keep code clean and prepares you for the next step. MVC the architecture is about how your application executes. When your first script runs for a request it will execute the controller, which may interact with models or do form processing logic or some other actions, and from there execute the view. The controller is typically a class because that's what it is in basically every other language and MVC implementation out there, but because PHP is not strictly OOP your "controller" could be code at the beginning of a file and the "view" the code that comes after. Professional means you get paid. It says nothing about your abilities or the quality of your code. There are far, far more bad PHP developers out there than good ones.

I don't see anything "first_child" on that doc page I linked, but that "How to traverse the DOM tree?" example looks highly relevant.

I saw. Just giving someone else a chance to say something. I'll stop by eventually.

Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things. Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price.

Fragmentation? I don't see how. Yeah. So? What's wrong with having multiple plans? Your business needs change over time, it's okay. And you could, if you wanted. But isn't it starting to get rather complicated? You have to look up pricing at that time, features at that time... It sounds cooler and making it more complex might seem like it's better, but what are you really gaining from it? How much time is it going to take to make this work? What is the risk of something going wrong? Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people.

Precisely. It gets easier with practice. Don't be afraid to do something because you're not sure you're doing it perfectly. I don't mean stuff like security, you really should try to get that right the first time, but site architecture and layout and those things: it's okay if you aim for v1 now and consider redoing some things later. If you want to start a new thread, go right ahead. It is a weekend so it's a bit slow around here, but there are enough people around here with experience who could chime in.

Billions. It's cheap to do now, you might as well. IMO looks more professional too. You'd have to move everything into partitions. A wise observation.

It's actually pretty simple: you create a brand new plan and make sure people can no longer choose the old one.

I'm talking strictly about where the file data is being stored. You can have your metadata (which you should, that's a good thing to do) in the database certainly, but there are more advantages to storing the actual data and transmitting the files from the web server than from the database. Having logs of adding, deleting, and updating these files doesn't require that you store the files themselves in the database too. Regarding too many files, for small sites it's not an issue, but it is good to partition them some. There are limitations to how many files can be in a directory, even if you are unlikely to hit that limit anytime soon. You could partition them by upload date (year/month/filename.ext) or uploader (user id-user name/filename.ext) or unique ID (last two digits of ID/filename.ext) or really anything else you can think of. You can always change this later, of course.

What you're trying to remember is called the complex syntax. Forgot to mention that earlier. Best practice with PHP is to keep logic (most code) separate from presentation (HTML and such). That means doing as much work in straight PHP as possible and having as little as possible, subject to interpretation, with the display. With a traditional PHP script where you do all the work for a page in the one file, possibly with includes, you do work in the top "half" of dealing with forms and looking up stuff in the database and all that, and in the bottom "half" you display whatever you need to display to the user. Since the display portion is going to be mostly HTML, it makes more sense to be out of PHP mode for the most part and then briefly jump into PHP mode when you need things like variables or control structures. It's also a lot harder for a good editor or IDE to provide you syntax support for HTML when you have to put them in PHP strings.

Yes. It kinda depends how paranoid you need to be. If you only care about images then it's pretty simple. Do restrict upload size through your php.ini or similar PHP setting. Do not use the "type" in $_FILES. Do not use the original filename, if you can avoid it, or if you want it then use basename() to get that portion of it and ignore the extension. Do determine the type of image yourself, like with getimagesize(). Do store the file using the correct extension for the image type. Do make sure your server will not try to execute any files in the upload directory (how you do depends on the server).

These things are always subject to personal style. I would do your code something like <table id="membershipPlans"> <!-- Column Groups --> <colgroup> <col id="feature"> <?php foreach ($plan_names as $p_id => $p_name): ?> <col id="option0<?=$p_id?>"> <?php endforeach; ?> </colgroup>

Create an include file just above your WWW directory that will define some very basic things. It will always live just above the WWW directory. Always. Put in it something like const INCLUDE_DIR = "some path to find your new include directory"; You can put other commonly-needed things in there too. Or include other files. Whatever. registration.php will include it with require_once $_SERVER["DOCUMENT_ROOT"] . "/../the new include file.php"; then it can do things like require_once INCLUDE_DIR . "/files.inc"; or whatever. There are better approaches to this problem but they will require more significant changes. For now, this is enough.

Ah yes, you are right. I said "CDN" but actually I meant some form of online storage, like Amazon S3. You could have a real CDN with it, or not. Whatever technically, point was a secondary location outside your web servers that was a singular location where you could keep the files. Perhaps your own file server, or S3/Cloudfront, or something else.

If you have multiple web servers, no CDN, and no other form of centralized storage, putting files in a database is how you can distribute the files across all the servers. Another is replication - databases exchanging data with other databases. If you have multiple database servers running with replication already, putting files in there means those files are replicated as well. I disagree. I'm rather surprised to even hear that statement being made. But why? Why store them in multiple places? There's no need. A file is more than just binary data. Smart browsers can recognize the data from a PNG image and not confuse it with a JPEG image. But not all browsers are good at that, and sometimes file data looks similar across different types. Which means you need to know the MIME type for a file and send it to the browser. Which means identifying what it is, storing it in your database, and sending it through your PHP script. Additionally, a request for a file doesn't have to be for the entire file. If you had a large file, a browser could try to download it, and if that process fails (eg, internet disconnected) recover from where it left off. When it tries to continue it tells the server that it doesn't have to send the whole thing - only parts of it, or starting from a certain offset. Managing that on your own in PHP is annoying. Web servers can do all that for you.

I would say storing in a database is not easier. The web server is capable of serving out static images very well, and if you store them in a database then the work to create a PHP script to support the same features as the server is not fun. Caching, MIME types, byte ranges... there's a lot to cover. You can do it, of course, but you only have one server so storing them as files is going to be much easier.

First, is this what you should be doing? Do you have a CDN? If so then you should be storing files there. If not then... well, it's kinda complicated. What's your architecture? How many servers and databases?

It may not be seen, but it can very easily be changed by anyone with a casual knowledge of how webpages work.

Not like that, no. use PrimaryTopic\SubTopic\SubSubTopic\ParentClass; class ChildClass1 extends ParentClass {

Have you checked the main documentation page? Yes, you can get to a node's children.

MySQL is enterprise quality. It is perfectly fine to store files in a database, but it does mean some extra work to be able to serve those images through a web server.

That would be if you fetched all the rows at once. You while($row = $result->fetch_assoc()) are only getting one at a time. Which is fine. Normal, even.

If you want to support ranges then you're going to have to normalize your data some. That means not storing strings like "Gen1:1" that you have to parse, and instead storing the book name, chapter number, and verse number separately. book | chapter | verse | text -----+---------+-------+----- Gen | 1 | 1 | some words Gen | 1 | 2 | some more words There is more you could do but I think this a big enough change for the time being. With this in place, searching should be much more straightforward. To parse a string like "Gen1:1" (one book, chapter, and verse) you can use if (preg_match('/(\w+[a-zA-Z])(\d+):(\d+)/', $string, $match)) { list(, $book, $chapter, $verse) = $match; } else { // invalid } To parse a range like "Gen1:1-Gen1:3" (must be the same book) or "Gen1:1-1:3" (same chapter) or "Gen1:1-3" (just the verse) you can use if (preg_match('/(\w+[a-zA-Z])(\d+):(\d+)-(?:\1?(\d+):)?(\d+)/', $string, $match)) { list(, $book, $chapter1, $verse1, $chapter2, $verse2) = $match; if (!$chapter2) { $chapter2 = $chapter1; } } else { // invalid } But to search on a range you'll have to be a bit creative. Give it a shot and see what happens. If you think you have it working, post what you came up with.

$row is only going to be a single row from the result. That means the syntax to get something in it would be $row["name of column"] without any [0]s or [1]s. I'm not sure why you seem to be trying to get two verses. What is some of the data you're dealing with and what are you trying to get your script to come up with? Also, when you post code, it helps if you use the <> Code button to add it to your post. You can skip the [...]s that way too. Also also, Notepad++ is a good editor and many people use it so that's fine, but it doesn't seem to do syntax checking without some setup. Google is your friend. If you want a recommendation of a whole different editor then I use VS Code with the Intelephense plugin.