Jacques1

Your getIt() function merely echoes the substring. It doesn't return it, so the value is lost.

The ZIP code and the time interval constitute the primary key. Each time interval has its own row (hence the nested loop). Then you also don't need an ON DUPLICATE KEY UPDATE clause, because there won't be duplicate keys.

I'm not aware of any rules for array keys. I tend to use underscores. PSR-4 (the filename and class name must match)

Regarding JavaScript: Crockford's Code Conventions for the JavaScript Programming Language I don't think it's explicitly mentioned, but most JavaScript programmers use camelCase (functions, methods, variables) and PascalCase (constructors).

PSR-1 Basic Coding Standard There are no explicit rules, but when you already use camelCase for methods and functions (as the standard recommends), it makes sense to use the same for variables and properties. What? That definitely depends on the concrete case.

I don't think you understand what GROUP BY means. Get rid of it. By using an alias.

The directory needs execute permissions, otherwise it cannot be entered. Of course there may still be other problems, but this is where you start. You should also forget about phpmyadmin for now and use the command line directly. If you still cannot access any tables, use mysqlcheck to check the database for errors.

Yes. If the user can easily select many ZIP codes, and if the code groups constantly change, then I would go back to your initial approach and simply repeat the data. Sure, an area would save a few rows, but it's also more complicated and less flexible. Let's say many ZIP codes have almost the same data. The easiest and most intuitive approach would be to first duplicate a set of default values and then adjust individual ZIP codes. This is somewhat difficult to implement with areas. When you have a set of ZIP codes and the corresponding data, you can insert everything with a nested loop (pseuco-code): insert_stmt = db.prepare('INSERT INTO forecasts (zip_code, ...) VALUES (?, ...)') each zip_code in zip_codes: each weather_of_interval in weather: insert_stmt.execute([zip_code, ...]) zip_codes are the codes which are eather selected on the same page or have been submitted on a previous page. weather contains the 10 data rows of your initial GUI.

Your project is not “massively complex”. It's just very vague. You've talked a lot about how you think the technical implementation should look like (most of which doesn't really make sense to me), but the workflow doesn't even seem to be clear at this point. If you don't want to have areas which cover multiple ZIP codes, where do the ZIP codes come from? Is the user supposed to enter a list of (arbitrary?) codes whenever the data is the same? That's doable, sure.

Sounds like you've tried “array[]”. That's not what I said. I'm talking about replacing “array()” with the new array literal “[]”. So instead of the keyword “array” followed by a pair of parentheses, it's now just a pair of square brackets without any “array” keyword, just like in JavaScript (or Ruby, Python, ...). If you're still not sure how the correct syntax looks like, read the manual. You can like whatever you want. I'm sure there are also people who like to write $a{$i} instead of $a[$i], and that's fine as long as nobody bothers to officially deprecate or remove this syntax. The point is that instead of the old, verbose PHPism “array(...)”, there's now a literal syntax which is compact, easy to read and consistent with other languages. The PSR documents use it (even though it's not officially endorsed), Laravel uses it, and just about every other big project has at least considered using it. The only reason why this hasn't always happened is because of legacy code.

So this is the non-fictional version of your previous question? I think this is a deeper problem of your class design, because a lot of this doesn't make much sense: What exactly does the “main” class represent? It seems to be a controller, a model and an authentication helper all at the same time, which is probably why it has such a vague name. Use separate classes for separate tasks. Why do you need multiple classes to represent the same table? What's the fundamental difference between the document types? Your constructors are weird. The sole purpose of a constructor is to initialize the object. It does not send JSON documents around or communicate with the client. If there's an error, you throw an exception. You can then turn that exception into anything you want on a higher level.

Yes, it is. PHP 5.3 is long dead, so the short array syntax is now available everywhere.

A constructor cannot return an arbitrary object. A new animal is in fact a new animal, not a new dog or cat. Mapping rows of the same table to different classes sounds like a strange idea to begin with, but that aside, you could of course use something like $animal = Animal::load(2); // returns an instance of some subclass of Animal

PHP isn't clairvoyant.

The “array()” syntax is obsolete. Use “[]” instead. The reason why you cannot add the array type hint is because the method you're overriding doesn't have it. Otherwise it would be perfectly valid.

[OP has cross-posted the thread on CodingForums] So the data is always the same for those ZIP codes? Then why do you even store it for each individual ZIP code? If you can only cover bigger areas, you should associate the data with those bigger areas.

ESPN cannot access any files on your PC. That would be horrible. What happens is that the client (Firefox or cURL) includes its stored cookies in the request so that the server can read those cookies. You can actually see this if you open the developer tools of your browser (usually by hitting F12) and inspect the traffic. It's very important to understand that cookies are managed client-side, which means they're under your control. You decide which cookies the server gets. You're free to send no cookies at all or even “fake” cookies created by yourself.

Again, every web client has its own cookies. If you use, say, Firefox and get cookies from ESPN, those cookies only matter to Firefox. cURL doesn't use them at all. The cookies managed by cURL are entirely separate, and you're free to delete or ignore them as you like.

Sites don't have cookies, clients do. Every browser and also cURL manage their own cookies. So whose cookies are you talking about? The cookies of cURL are stored in a simple text file which can be inspected at any time. If you want to check if the cookie is still accepted by the server, you would of course have to make a request and use heuristics to determine if that's the case (like parsing parts of the website or trying to access a page which is only accessible with a valid cookie).

This looks like a circular dependency: Your index.php includes the database_class.php, but the database_class.php in turn includes the index.php. If you didn't have the require_once, you'd actually run into infinite recursion. In any case, the script layout is very confusing and poor. A class file shouldn't do anything but define a class. It should definitely not run some index.php script with side effects.

The WordPress ecosystem is infamous for its lack of security and has almost 1,000 entries in the CVE vulnerability database, not to mention the long history of high-profile attacks. And given your attitude towards security, it's hard to believe that you're running a carefully hardened server. This is anything but a “completely closed system”. A single SQL injection or cross-site scripting or cross-site request forgery attack can be suffient to inject code into a post. And once that's done, the attacker has direct access to your server.

Get rid of the plugin. Allowing arbitrary code execution within posts is already a shitty idea. But doing it with an obscure plugin that seems to have been published somewhere in 2009 and never updated since is suicidal. How about setting up a proper, secure Wordpress installation? It's really not that hard.

The code is currently too trivial for any kind of meaningful feedback. You have an HTML form, hard-coded dummy credentials and a few session values. That's great, but it doesn't really show anything. It would be a lot more interesting if you had an actual log-in system with a database and password hashes. Until then, all I can say is this: Learn and apply the basics of security as early as possible, especially when you write a log-in form. This includes HTML-escaping values before you insert them into your HTML markup so that an attacker cannot inject malicious JavaScript code. Keep PHP and HTML separate. It makes no sense to do session management in the middle of the body element. You should have a block of PHP code on top of the script and then all HTML markup at the bottom. The only time you use PHP within HTML is when you need to display dynamic data (like the username from the session). The register button which changes the location through JavaScript is odd. Use a plain old link instead. When you redirect the user with a header() call, you must stop the script with an exit statement. Otherwise the code will keep running, which can have dangerous side effects. Don't use spaces in URLs (or other characters which have to be encoded), and don't mix lowercase and uppercase letters. “Rede%20Social” is difficult to read and just ugly. Why not “rede-social”?

Your upload directory path has no trailing slash, and you just append the filename. This will lead to a file with the name “VID...” rather than a file in the “VID” directory. And you indeed don't display any errors. You return a message in your function and don't do anything with it in your main script.

The “about-us” is just additional information which gets sent to the index.php script. What the script does with this information and where the page content comes from is completely up to the developer. Only the code will tell.