requinix

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);

Someone (I think it was me) originally suggested the RecursiveDirectoryIterator in another thread, but the output requirements made it easier to use scandir/glob and do the recursion manually. ...at least that's what I remember. I thought it was supposed to show files before directories too, but the posted code won't do that.

If fixing file_match($full_path, $pattern);that to use $patterns doesn't solve the problem, what is the current output?

It'd be really nice if your site could take orders for franchises too... Like, if that were possible, then you could allow the online ordering as normal, then when they enter their address you can locate nearby franchises and give the user the option to order from them directly. I feel bad for diverting you from entering a city to using geolocation - it's more complicated than I think you or your boss was expecting. So, Simpler than the geolocating stuff would be to present a map to users showing all your franchises with links to, well, wherever the franchise prefers (like their Facebook page). Using just the IP address you can generally narrow down their location to a city or shire and then automatically put the map at that location, so there's no "site wants to access your location" message from the browser (which, for desktop users, probably wouldn't be much more accurate than with an IP address anyways). I don't know any examples of this off the top of my head, but I know they exist. Again, the idea is that the user can be on your site without any intrusions but can find nearby locations easily enough.

What about the people who have a franchise nearby but want to order from the online store? The standard way to approach this problem is to give them to option to find nearby stores. Don't require them to do it at any point as it's more likely to frustrate users. You should give them the online store by default, then make it easy for them to find a nearby store. You can then add support for geolocation which will assist with the latter by automatically determining where the user is - if the user('s browser) allows it. For example, Sainsbury's has a "Store locator" link at the top which takes you to a map where you can find stores automatically (⦿ button) or search for one normally. What do you think? It's more work but I think it's better for the user as it's more consistent with other sites.

Plenty of people here could write it for you, but instead we're going to help you write it. Are you going to do this using PHP or Javascript? You'll need one or the other because HTML and CSS alone can't do it. But, actually, requiring people to type in their town isn't very nice. If you want to learn how to do this in principle that's one thing, but if you want to put this up with your company's site for real then we should talk about other options.

Sounds like you're stuck with having that client, then. That's too much C to translate into PHP. I'd try to build a small CLI program (in C) that spits out whatever data it gets in text form, then the PHP client can run it as a process (ie, with proc_open) and parse the output as needed.

Can't the C++ app connect to the "server" itself directly? Why set up the "client" middleman? The app is the limiting factor here. What capabilities can it have? Has it been (mostly) built already? Can it handle doing HTTP requests? Is there a reason you need the app and can't do the work in PHP?

Your terminology confuses me. There should not be one "main" view file. Each view should be related to a controller, or be a partial view if your framework can do those, and each controller should be invoked according to the request being received by the server. Process goes 1. Server receives request from client 2. Framework interprets request and locates corresponding controller 3. Controller executes and indicates which view to render 4. View renders In your case the request is the AJAX stuff and eventually the view renders JSON or an HTML fragment. The controller could be this "API file", but better practice is to have one controller for each logical process (ie, API endpoint).

Replacing the file probably won't fix the problem. The point is to get a backtrace more useful than "stack": [ { "line": 4, "func": "removeAttr", "context": [ "/*! jQuery v2.1.4 | (c) 2005, 2015 jQuery Foundation, Inc. | jquery.org/lic//...", "!function(a,b){\"object\"==typeof module&&\"object\"==typeof module.exports?mod//...", "return M.access(a,b,c)},removeData:function(a,b){M.remove(a,b)},_data:funct//...", "void 0===c?d&&\"get\"in d&&null!==(e=d.get(a,b))?e:(e=n.find.attr(a,b),null==//...", ";", "", "function sprintf() {", "/*", " * Copyright (c) 2013 Kevin van Zonneveld (http://kvz.io)" ], "filename": "jquery/jquery-2.1.4.min.js" } ],this minimized mess. To identify the problem - or at least get a lead on it.

The purpose of the alt is in case the image cannot be loaded, plus accessibility stuff. Making it an image too doesn't make sense. If you need some kind of fallback, use Javascript to detect the un-loaded image and replace it.

Manually replace jquery-2.1.4.min.js with the non-minimized version and see if you can get a decent backtrace. And try clearing your cache. [edit] Apparently you already know about the clearing the cache thing, but don't know how. Does phpMyAdmin even have a cache?

Okay... And read this. I'm not asking to be annoying. I'm asking because nobody here is psychic. Nobody knows your application. Nobody knows its code. Nobody knows anything about it except for you, and if even you don't know how to do this then how could we?

What code? What data? How is it hidden and shown? What is GetData? How does it work? Is there AJAX? Is the data already on the page?

tl;dr: I'm getting old and set in my ways. I get what that guy is trying to say, but I particularly disagree with To me, the definition is not saying "I need a translator interface" but "I need a thing that acts as a translator"; "interface" is a technical term that I recognize for the mechanism that separates a thing that does (object) from a thing that can do (interface). And that is actually what it needs. It does not need a particular object from a particular inheritance hierarchy: it needs some kind of object that can fulfill the "can translate" requirement. That may very well end up being from a particular inheritance hierarchy, but as a KlingonDecoder I don't need to enforce that constraint. With languages like PHP that only support inheritance from one parent, classes need to be careful about what they extend, and if I intend to create a protocol droid* that is capable of translation then I'm certainly not going to make my choice of parent class be a Translator. On that note, "Translator" sounds like an actual thing that translates (an object) but "ITranslator" or "TranslatorInterface" make it clear that yes, they do translation, but they only dictate the ability to translate. Backing up a bit: That's a known problem with newbie/new-to-OOP programmers: not understanding the differences between the object and interface paradigms. Objects as real-world counterparts acts as an easy (if inadequate) analogy and makes initial comprehension straightforward, but interfaces don't have one. Interfaces look like mysterious classes that don't have any code... but abstract classes don't have any code either, so are they the same thing or what? It's an education problem. Teach people about objects and interfaces and suddenly the naming problem goes from "I need a translator so I think I need a Translator and not this weird TranslatorInterface thing" to "I need a thing that can translate, and since I don't need a particular Translator I think I should use a TranslatorInterface". And back to naming, I tend to use -able when it creates a reasonable word, but making sentences is introducing a whole 'nother problem. I know that "Jsonable" is a bit awkward, but as an English speaker I don't need a dictionary to know what it means: able to become Json. It's short and simple. As a descriptive term you'd want "CastsToJson"? But it's not actually a cast. So "ConvertsToJson"? Converts itself or other data? "SerializesToJson"? How does it serialize? "ReturnsSerializableData"? How is that data serializable? I can keep going. To me, the whole blog entry seems based on a knee-jerk reaction to the fact that interfaces are becoming more and more popular - in the same way that singletons and registries did, and quite possibly to the same conclusion. The names are a red herring. * Yes, I know, wrong universe.