Jacques1

Then use ODBC. You have my permission.

I don't think you understand what requinix is saying. The current code makes no sense. You're trying to parse the PHP output as JSON data, but there is no JSON data anywhere. So the code is stolen somewhere from the Internet, and you have no idea what it's doing, right? This doesn't work. You need to understand the code and adjust it to your needs. Or hire somebody to do the thinking for you.

What is the purpose of this “PIN”? What prevents me from going directly to pinI.html or pinII.html?

Read the troubleshooting guide. Turn debug output all the way up so that you get concrete messages (for some strange reason, you've commented this out). Try 'tls' on port 587 rather than the nonstandard 465 port .

This still doesn't make much sense, and there's no PHP function which could do that for you. The DateTime::diff() method calculates the actual number of days, months and years between two dates. If you want to “add” another interval using your own logic (“one month is 30 days”), you have to do that yourself. That is, you must add the days of both intervals, divide the result by 30, then add the months etc. Like I said, there is no PHP function for this kind of logic.

So, how does this not do what you want: <?php const PATH = 'X:/testfolder1/Monthly Files'; const EXTENSIONS = ['doc', 'zip', 'pdf']; $dirIterator = new RecursiveDirectoryIterator(PATH, RecursiveDirectoryIterator::SKIP_DOTS); $fileIterator = new RecursiveIteratorIterator($dirIterator, RecursiveIteratorIterator::SELF_FIRST); foreach ($fileIterator as $file) { if ($file->isDir() || ($file->isFile() && in_array(strtolower($file->getExtension()), EXTENSIONS))) { echo "$file<br>"; } }

You should forget about the “perfect way”. That's really not the issue right now. I think a more realistic goal is to get a basic understanding of OOP and write simple dummy classes just for the sake of learning. If you don't know how attributes work, you should start with that. Start with the basics before jumping to advanced topics. For example, if you write a proper File class which can read() and write(), that would be infinitely more useful for this discussion than all the fancy interfaces and design patterns. In any case, there will always be multiple approaches. OOP is still programming, so it's still a matter of experience, creativity and personal preferences. There is no simple ruleset.

Note that PHP has several iterators and functions which can traverse directories just fine (and even filter the filenames). There's really no reason to implement that yourself.

I understand your approach, I understand this is all work in progress, I understand you have legacy code. Nothing wrong with that. I'm a programmer myself, so I'm aware that projects take time. By the way, it's perfectly fine to embed OO components into procedural code, because the programming paradigms are not mutually exclusive. What I fail to see is the OO part. So far, your objects are just containers for functions. They have no attributes to hold their state, they have no task which they take care of autonomously. See what I mean? That's why I suggested a few design patterns as a starting point. If you want to implement your own CRUD operations with your database classes, that's also fine. But you should at some point make the transition from function containers to actual objects.

I recommend you read my reply: But, yes, you definitely need to work on your error reporting. This or die(...) pattern may be very popular, but it's nonsense. When an error happens, you want two things: Log the exact error message reported by MS SQL Print a generic error message on the screen for the user (and set the appropriate HTTP response code). Unfortunately, the mssql_* functions are old and crusty, so this will require a lot of work. Do you have to use them? There are MS SQL drivers for the PDO interface which are much more modern and can do the error reporting automatically.

This is more concrete. Unfortunately, you're still thinking purely procedural. Your “class” is just a bloated function: You call connect(), you get back a connection, and that's it. You might as well have written a connectToMySQL() function. There isn't anything resembling OOP. Do you really want to learn OOP? I don't mean this in a hostile way. I'm simply observing that you have not adopted the OO paradigm at all. You're thinking and programming in terms of functions – which is perfectly fine. A lot of great applications are written in procedural code, and a lot of programmers simply aren't interested in OOP. But then you should in fact choose the procedural approach. It doesn't make sense to throw classes and interfaces around when you really just want to write functions. If you do want to learn OOP, you have to be willing (and able) to change your way of thinking. Procedural code is about tasks: You validate the request, you connect to the database system, you send a query etc. OOP is about actors communicating with each other: The request router delegates the request to the controller, the controller validates the input, asks the database object to store the data etc. This is fundamentally different. It's a much more abstract, much more top-down approach to problems. It's not procedural code with some classes. It might actually be a good idea to start with very simple examples before jumping to real code. Yes, it feels silly to write a Person which has an age and a name and can sayHello(). But maybe that teaches you more about OOP than all of the previous threads.

Whatever that is, it's not valid PHP code either.

Can you be a bit more specific than “doesn't work”? Are you getting your “Error Querying ...” message? Does the program crash? Does it keep running but has no effect? The mssql_query() function expects the query as the first argument (read the manual), so I'm fairly sure you do get a proper error.

You have to make sure that the WordPress session cookie is also valid for your main application. Open the developer tools of your browser. What does the path attribute of the cookie say?

I was talking more about the specific interface and classes above. Right now, there's only one method, and that method doesn't have any effects. So commenting on the code is a bit like having to comment on procedural code that only consists of a few empty functions. What can you say about that? If you fix the connect() method and add at least a few dummy implementations for other methods, I'm sure we can give some feedback. Alternatively, you could do research on common implementations which range from simple utility classes to complex object-relational mappers (Data Mapper, Active Record).

Oy vey. Like I said, you really, really need to learn the basics before you start typing code on your keyboard. You do not store comma-separated lists in a database. I understand that you absolutely love comma-separated lists, but this is not how the relational model works. One field is for one value. Not four values. One. So the first step is to repair your entire database. When that's done, we can go back to my query in #6.

I understand what you're trying to do. I'm saying that your code doesn't do what you want it to do. You don't understand your own code. Your code is written as if multiple subjects could have the same ID (e. g. “Math”, “Portugese” and “English” would all have the ID 1). This is obviously not the case. I assume what you actually mean is something like this: <?php $departments_stmt = $DB_con->prepare(' SELECT deparatmentos.departamento FROM visitas_estudo JOIN deparatmentos ON visitas_estudo.dpt = departamentos.id_departamento WHERE visitas_estudo.id_visita = :id_visita '); $departments_stmt->execute([ 'id_visita' => 28, ]); $departments = $departments_stmt->fetchAll(PDO::FETCH_COLUMN); // $departments is an array of all department names; you can now implode() it or whatever

The code in general doesn't make much sense. First off, you need to learn some database basics like joins. This is how you connect tables in the relational model; you do not execute queries in loops in your application. The queries themselves are also strange. You first fetch a bunch of department IDs. Then you look up the department for each ID. But you seem to expect multiple departments per ID, because you're again using fetchAll(). How is that possible? Isn't the ID supposed to be, you know, unique? It would also help a lot if you used meaningful variable names in English instead of this English/Spanish(?) mixture.

The mysql_* functions are ancient and have been removed from the latest PHP branch. Use PDO and specifiy the socket path either in the DSN string or in the PHP configuration.

It's difficult to comment on the code at this very early stage. The class structure makes sense: There's an interface and multiple implementations for the different database systems. But the connect() method doesn't do anything. It creates a PDO instance, stores it in a local variable, and then everything is discarded. What did you actually want to do? Put it into an attribute? Return it? Something else? And which features are you planning to implement? Where is this going?

That might be the only good idea in this entire thread.

The database code doesn't make much sense. You're using prepared statements (which is good), but then you're just inserting the input right into the query string. You call fetchAll(), ignore the result and then call fetch(). What is this supposed to do? You also keep overriding your variables everywhere. On top of that, running queries in a loop is very inefficient. You should learn some database basics before jumping to complex applications. Combining tables is done with joins. The point of prepared statements is to pass all input through parameters. You should pick one fetch method. And it helps a lot to have meaningful variable names. If all of them are called $query and $row, you're almost guaranteed to end up with collisions. <?php // make PDO::FETCH_ASSOC the default fetch mode instead of repeating it over and over again $product_stmt = $db->prepare(' SELECT product.product_id, product.product_name, product.product_price, product.product_image, cart.qty FROM cart JOIN product ON cart.p_id = product.product_id WHERE cart.ip_add = :ip '); $product_stmt->execute([ 'ip' => getIp(), ]); $products = $product_stmt->fetchAll(); And as multiple people have already told you, using the IP as a customer identifier is a major design error. It means that a customer may end up sharing “their” cart with hundreds or thousands of other people whom they don't even know.

Before we can even talk about code, we first need to figure out what you want to do. We cannot read your mind. You have to actually tell us what you're working on. If you cannot or don't want to do that, it's impossible to help you.

This is still gibberish. Forget about PHP scripts doing this or that. Tell us in plain English what you're working on. A chat? How does that chat work, and what do you want to achieve?

You cannot set cookies after you've generated HTML markup. Cookies are set in the HTTP header, but the markup is in the HTTP body which comes after the header. Once you start sending body data to the client, it's too late to do anything with the header. PHP cannot travel back in time (it can theoretically buffer the message, but this is complex and not recommended in your case). So you have to set the cookie before you generate any page content. There must be no output before the setcookie() call. No <html>, no <head>, not even whitespace. Nothing. As I already said, you need to fix your spaghetti code. I -- again -- strongly recommend you set the cookie with JavaScript. Not with PHP. With JavaScript. If, for some strange reason, that's not an option for you, you'll have to reorganize your PHP script to look something like this: <?php // this is the first line of the script; there must be nothing before this if (isset($_COOKIE['modal_seen'])) { $show_modal = false; } else { $show_modal = true; setcookie("modal_seen", "true", time() + 3660, "/"); } // now the HTML markup ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Title</title> </head> <body> <!-- ... --> <?php if ($show_modal): ?> <script type="text/javascript"> $(window).load(function(){ $('#modal-box').modal('show'); }); </script> <?php endif; ?> <!-- ... --> </body> </html> I strongly recommend against this. It's just bad programming.