requinix

PHP won't show a white screen without some indication as to what went wrong. Did you do the settings thing I said? Also, you've missed the point of how prepared statements work. Don't put values straight into the queries: "WHERE tc_id = ".$testcaseIdUse a placeholder, like :testcaseId "WHERE tc_id = :testcaseId"and then use the actual value with either bindParam() or execute(). The former would be easier for your code. $stmt = "..."; $stmt->bindParam(":testcaseId", $testCaseId, PDO::PARAM_INT);

You're not doing this with your own website, right? Where are these links coming from, exactly? The BRs are annoying. How about using smarter HTML, and perhaps a dash of CSS, to get the same effect. Are you looking for a list? <ul> <li><a href="/category/category-1">Category 1</a></li>If these things represent a list, like logically they form a thing you would call "a list", then a UL would be the most appropriate way to show them in HTML; if you don't want to see bullet points then they're easy enough to remove. But there's a larger problem: getContents() will only give you the URLs. No "Category 1" and whatnot that was used as the link text. If you need that then... well, sorry, but the DOM method is not only superior to doing string math but can also get you both the link and text at the same time with no additional work (less work, in fact).

switch($operation){Where is $operation being set? No $operation means no $stmt and so the $stmt->execute();will fail (calling a method on a non-object) and PHP will die. If you aren't seeing that error message then your environment is not correctly set up for PHP development. Find your php.ini and change two settings: error_reporting = -1 display_errors = onThen restart your webserver and try that first script again.

There's many ways you code show the links so you'll need to be more specific. Do you maybe know the HTML you want to see? If the links were "https://forums.phpfreaks.com" and "http://www.google.com" then what should you end up with?

Thread pruned. Next time this happens I will hand out bans. MrLeN, the best thing really is to use something that understands HTML and have it extract links or whatever. You said you tried it and couldn't get it to work? What code do you have and how is it not working? If you don't want that and think that the earlier code is good enough, The return value from getContents will be an array so you can't simply print it. As Barand said, you can use a foreach to deal with it "properly", or print_r/var_dump to simply see what's in there (like for testing). Or something else that depends on exactly what kind of output you're trying to get.

"It doesn't work" is meaningless. How does it not work? Assuming you have DNS set up correctly, RewriteCond %{HTTP_HOST} ^test247.info$ [NC]that will only accept "test247.info" as a domain name. Not "www.test247.info". Modify it to allow for an optional "www.", or add a second RewriteCond with an [OR] to match that name.

What you're doing is completely disregarding what I and Barand said. Your database table uses columns like FName and LName. If you're okay with using those in your JSON as well then do what Barand said. If you want to keep the "First Name" and "Last Name" keys in your JSON then either do what Barand said after modifying your query to use aliases (like "FName AS `First Name`") or do what I said. Neither of those options involve building $outp as a string.

Maybe someday they'll be even more useful

Don't try to build JSON strings yourself. It's silly. If you want a JSON representation of an array (or object) then use an actual PHP array and json_encode it. $outp = ["records" => []]; while($rs = $result->fetch_array(MYSQLI_ASSOC)) { $outp["records"][] = [ "Portrait" => $rs["Portrait"], etc. ]; } echo json_encode($outp);

Have you looked at the HTML source of the page you're trying to copy? It references stylesheets and images and code. When I run your code from my "website" most of those references will break because the files don't exist, and it happens to break in such a way that most of the page is missing/not visible. Unless you cloned the assorted other files, I would expect the same when you try it. The redirect is completely random. Here's another thing to try: running it locally. Start the built-in server php -S localhost:8000 -t /path/to/where/your/test/file/isthen go to http://localhost:8000/file.php and see what happens.

I tend to revise my posts a few times before posting. Occasionally words get lost. Words such as "to". A calculator has calculator-like behavior, such as "put the current value into temporary memory" or "calculate the result of this expression". A class can be a calculator, and an interface can say that a class behaves like a calculator. interface ISaveRestoreState { public function saveState(): string; public function restoreState(string $state); } interface IEvaluateExpression { public function evaluate(string $expr); } interface ICalculator extends ISaveRestoreState, IEvaluateExpression { } class MobileCalculatorApp implements ICalculator { ... } class DesktopCalculatorApp implements ICalculator { ... } Which "this"? If you find yourself wanting to copy code from one class into a new sibling you're writing then it's easy to pull code out of the one class and into an abstract parent instead, so there's no need to do it ahead of time "just in case". So if you feel better about it, don't use an abstract class until you need it. My experiences may be a bit atypical as I tend to write lower-level code than the average PHP developer. More often than not I will build something from the ground up than from the bottom down, and I have no problem adding an extra class or two because I anticipate a need for them later. Like right now, in my own code I have basically // rendering a thing is a behavior that isn't confined to a particular type of object interface IRenderable { public function render(); public function renderToString(); } // view is a renderable thing abstract class View implements IRenderable { // likely the method that will be implemented by a child public abstract function render(); // I can implement this here so the child doesn't have to public function renderToString() { ob_start(); $this->render(); return ob_get_clean(); } } class StaticFileView extends View { // ... // required implementation public function render() { readfile($this->file); } // I could use View::renderToString, however I can do it more efficiently myself public function renderToString() { return file_get_contents($this->file); } }The whole point of the abstract View is so that child classes don't have to implement renderToString by themselves, even though some may want to. It's a matter of practicality and code reuse. For the most part if code needs to deal with rendering a thing then it will work with the IRenderable interface. Don't worry so much about all this. You're asking questions that are best answered with experience and that can't always be expressed in words. Do something for a while and think about how it worked out; if you decide it was really bad then you can go back and refactor, but if it really was that bad then you would probably have realized sooner so it's not actually as bad as you think.

On the simple directory listing: Make sure you don't have an index.php or .html or .anything in the PDF directory or any of its subdirectories. Now go to /PDF in your browser. What happens? If you get a 403 Forbidden page then that can be fixed, but there's a good chance you'll get a listing of all the files and directories in there. And with no* work on your part. * Your experience may vary.

1. Aren't you already doing that? I see one ++ and three +=. 2. You are using custom logic in there. I don't see a way to clean it up - you'll just add more complexity for little gain. 3. Sessions are the way. I wouldn't expect you could remove or modify any of that logic, but you could go OOP and modularize it. By that I mean something like class Player implements Serializable { public $id; // presumably you have one public $level; public $hpmax; public $strmax; public $defmax; public $strength; public $hp; public $def; public $seen_master; // ... public function notSureWhatThatCodeRepresents(Mob $mob) { $this->level++; $this->hpmax += $mob->hp_buff; $this->strmax += $mob->str_buff; $this->defmax += $mob->def_buff; $this->strength = $this->strmax; $this->hp = $this->hpmax; $this->def = $this->defmax; $this->seen_master = true; $this->updatePlayer(); } } class Mob implements Serializable { public $hp_buff; public $str_buff; public $def_buff; // ... } $_SESSION["player"]->notSureWhatThatCodeRepresents($_SESSION["mob"]); $_SESSION["round"] = $round;The logic is the same but you've contained it in one place, and the code that uses the session only needs to call methods to do what it needs. There is a caveat with storing objects in the session: all properties are serialized, so if you change your code then sessions could break. The good news is that you can get the benefit of having objects in the session without the downside by modifying how the objects are serialized: // Player:: public function serialize() { return $this->id; } public function unserialize ($id) { // populate $this from data from... wherever you get the data from }That only stores the ID in the session, so as long as IDs don't change the unserialization will always work. And advice that may not apply: don't use the session as a way to shuffle data between specific pages that you expect the user to follow along. For example, say the user triggers a battle between their player and some particular mob. This takes them from page A (list of mobs) to page B (fight). The player can go in the session because it's a global concept that you'll likely need everywhere. Don't put the mob in there because (a) it's only useful for page B and (b) it requires the user go from A to B without stopping anywhere else. The latter is the bigger issue because if the user does not make that transition, even if your site makes it more-or-less automatic, then you have stale data in the session and that data may cause interesting side effects on some other page C. Worse, if you have page C to pick a pet to train and page D to do the training, if the player goes from C to B then they might accidentally fight their pet, or weirder page A to D might "train" a mob. (An unlikely example but the point still stands.)

I know that you didn't show the literal contents of some file because your post is missing the opening <?php. Is there anything else you didn't include?

Well, when I tried your code I got a page that was empty except for the logo and black background for the navigation bar, so...

Your code is just dumping the HTML out to your browser. If there is any redirect then your browser is doing it, so use your browser's tools to find out why. For example, have it track HTTP requests, find the one that performs the redirect, and see what originated it.

Sounds right to me. It's not one question about whether you should use both. It's two questions: one about using interfaces and one about using abstract classes. Interface: Does a class try to promise a certain behavior? Could that behavior exist with another class not in this hierarchy? Is the behavior a secondary aspect to the original class? Does the behavior have a more "can do X" attitude rather than "is a Y"? Abstract: Are you planning to (or at least leaving the door open to) subclass this class? Will there be some amount of code that's probably going to be needed by all subclasses, or at least most of them, but some portion that is not known yet?

That big HMTL string your PHP outputs echo "<p> sn: " . $data[$i]["sn"][0]."<br/>"; echo "givenname: ". $data[$i]["givenname"][0] ."<br/>" ; echo "employeeID: " . $data[$i]["employeeid"][0]."<br/>"; echo "distinguishedName: " . $data[$i]["distinguishedname"][0]."<br/>"; echo "displayName: " . $data[$i]["displayname"][0]."<br/>"; echo "sAMAccountName: " . $data[$i]["samaccountname"][0]."<br/>"; echo "department: ". $data[$i]["department"][0]."<br/>"; echo "manager: " .$data[$i]["manager"][0]."<br/>"; echo "mail: ". $data[$i]["mail"][0]."<br/>"; echo "title: " .$data[$i]["title"][0]."<br/>";is useless. Use JSON instead. 1. PHP will report that you're outputting HTML by default. You are not. Override that with header('Content-Type: application/json');at/near the top of your code and before you try to output anything. 2. Replace all your error messages with JSON. I suggest something like //echo '<p>LDAP SERVER CONNECTION FAILED</p>'; echo json_encode(["success" => false, "error" => "LDAP SERVER CONNECTION FAILED"]); exit;That is, a "success" that is true/false (false for errors) and an "error" with the error message. 3. Get rid of silly little status messages. //echo 'login successful';4. Replace your normal output with JSON. You can probably use $data mostly as-is, and you don't need to check how many results there are either. $data = ldap_get_entries($ldap_connection,$result); unset($data["count"]); // don't need this, it screws things up echo json_encode(["success" => true, "results" => $data]);"success" just means that the lookup happened succcessfully and "results" will tell your Javascript about the results. Now fix your Javascript to work with the new output. 5. Put dataType:"json" in the settings that you pass to $.ajax. 6. Remove the $(...).html(data) you have now because that's not what you want and won't work anyways. 7. The success callback's "data" will be an object. Do with it whatever you want. You can use data.success to tell if there was an error or not; if there was then you can use data.error for the message, and if not then data.results will be an array you can loop over normally for (var i = 0; i < data.results.length; i++) {If you have problems, post your new code with an explanation about what it is doing.

https://forums.phpfreaks.com/topic/303060-how-to-pull-selected-attribute-data-from-ajax-called-data/

You should define properties, with or without defaults. Putting them in the class helps to document what the properties are, and personally I give defaults (even just 0 or empty strings) to be clear what type of values it will have. I mean, look at Car: class Car { public $color = 'red'; } class Car { public $color; } class Car { }The first has an obvious property, and the default may or may not make sense but at least you get a feel for it. (In this example I don't think having "red" makes sense.) The second has an obvious property but it's not clear whether it might have a string, int, or object as its value. (Docblocks are good for that too.) The third is completely unhelpful.

You're already receiving the data from PHP: in the success callback, data will be that "Retrieved * Active Directory users" string. Don't parse it as JSON, do use it however you want. If you need help with the "use it however you want" part then you'll need to be more specific about what you want to do.

Did you not write that? Not sure what it's doing? Then you need to learn Javascript. There's a line of code in there that pretty clearly tries to parse a value as JSON. The error message gives you a pretty big hint. Remove that line.

You're not returning JSON. Don't try to parse it as JSON.

Check your variable names.

Oh, right, that was it. If you want to separate files and directories then you need to separate the files from the directories: go through the directory putting files into one array and directories into another. Afterwards you can print out all the files and then all the directories. // obviously not actual php code: files = [] directories = [] for each thing in directory { if thing is file { files[] = thing } else { directories[] = thing } } for each file in files { show file } for each dir in directories { show header call file_match recursively }But since scandir() does not sort filenames, you'll need to do that yourself with sort() - before the output happens. You could use glob, which does sort, but it also returns the full file path so one way or another you'll have an extra line of code somewhere. sort($files);