requinix

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.

Then you probably have a UTF-8 BOM at the beginning of the file. Open your normal editor and make sure it is not saving your files with a BOM. You may have to re-save all your PHP files once that's disabled.

Yeah, unless there is a particular need for that 1/2, 1/3, 1/4, 1/5 list then it really should be an array containing one entry for 1, that itself has another array of 2-5. array( "text1" => array( "text2", "text3", "text4", "text5" ) ) or array( array( "name" => "text1", "items" => array( array( "name" => "text2", "items" => array() ), array( "name" => "text3", "items" => array() ), array( "name" => "text4", "items" => array() ), array( "name" => "text5", "items" => array() ) ) ) ) Also your HTML is incorrect: the UL needs to be within the parent LI. Outside it is invalid. Keep in mind that ->find() will find all children, so ->find(a) on the text1 LI will find all five links. A better approach would be to find the A from the LIs set of immediate children, then from there go recursively into the immediate child UL if any.

That is the part of the message that matters. What is the first few lines of your index.php?

Working with those numbers as a string is proving to be a pain, isn't it? Then don't work with them as a string. Use an array, for both the input as well as the stored numbers. You can display them as a hyphenated string, but internally keep them as an array. explode() and implode() can help you convert between the two forms. Then the problem is how to take an array of five numbers and check against other arrays of five numbers to find what they have in common. Fortunately there's a function for that.

If you used actual NULLs and not 0000-00-00 dates then you wouldn't have to care about them. It's also better from a purist standpoint as a lack of data is what NULL is supposed to mean. SELECT * FROM Prospects WHERE UserID = ? AND FollowUpDate < ? Because comparing NULL with anything fails so those rows won't be matched.

Take a look at the code where you fetch the verse from the database. if ($result->num_rows > 0) { // output data of each row while($row = $result->fetch_assoc()) ; //$conn->close(); } Here's the thing: $row is only useful inside the body of the while loop, so... where is the body of the while loop?

You could do it with PHP, but the more you learn and advance with web development the more you're going to need to know Javascript and understand things like AJAX. One step at a time. Get the rest of your idea in place, the stuff you already know how to handle, then when you get to the trophies you can think about how to use the opportunity to expand your skillset.

You should not be sending emails as "From:" the user's email address. Because it will look like spam. Put their email as the Reply-To instead.