requinix

Try picking up React(js). Installing it, its requirements, and the typical packages necessary to work with it, totals something like 16k files and a few hundred MBs.

I'm certainly not going to be the first person in line to say that Laravel is a good framework, I have to work with it every day and I hate it, but as far as MVC is concerned I think it does a fairly reasonable job of it. Sticking with the aircraft analogy, I see what I'm suggesting more like sitting in the copilot's seat: as long as one has the mentality of learning how stuff works rather than trying to shoe-horn their experience into it, seeing how a professional system does the job is a good thing. Yes, Laravel has a lot of crappy magic in it, debugging the internals is hell, and the few parts it does well are beyond the scope of learning MVC, but the point is not to copy and paste but to understand the principles. Like for MVC, routing goes through some configuration layer (routing), to a controller, to a view. If I had more experience with other larger frameworks then I'm sure I would rather recommend them. Have I mentioned I don't like Laravel? The real basics, like cutting down on procedural coding or improving code quality and reuse, can be learned anywhere, and I think doing that in a framework which already tries to urge you into it is as good a place as any. In fact using a framework is like the middle seat: you don't have the window to look out unless you're sly and you don't have the aisle to stretch out into, so you have to learn to stay within the boundaries established for you. Yes, that analogy was rather turbulent, but I've reached a cruising altitude with this aviation metaphor and I don't want to land while I still have fuel in the tank.

A JOIN will find all combinations of rows that match your conditions. If you look at the results, every row has slightly different data - the player_id, stats_date, or type. Each of those rows fits your criteria, so if you don't want some of them then you need to adjust the conditions accordingly.

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.