requinix

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.

Hidden inputs are all sent with the form when it's submitted. However submit buttons ( and ) and image buttons () will only send themselves when they are used to submit the form - and only one of those can happen at a time. So what you need to do is figure out what image button was clicked. 1. Remove the hidden inputs since they're not helping you. 2. Give names to the image buttons (eg, "toner"). 3. Look for each button to tell which was clicked. Note that there will not be a "toner" but instead "toner_x" and "toner_y" values.

Don't hijack threads. You saw the code in the other thread, I assume? Did you try modifying it? Do you have any code written yet?

It doesn't matter as long as you're consistent. I personally like the .NET approach of naming I*. I know some open-source projects use *Interface. I've even seen them named interface_*, thus putting them in their own directory at the top-level, but I think that's silly.

Get it from the HTTP_AUTHORIZATION header in $_SERVER, then do rudimentary string operations on it. if (isset($_SERVER["HTTP_AUTHORIZATION"])) { list($type, $data) = explode(" ", $_SERVER["HTTP_AUTHORIZATION"], 2); if (strcasecmp($type, "Bearer") == 0) { // use $data } else { // ??? } } else { // ??? }Bearer is a not yet official method of authorization that people made up a while back because Basic and Digest weren't working well enough. It just means that whatever token comes after is some special code that the server will recognize for authentication - what actually happens with it is up to you.

Brain farts are an acceptable excuse.

You don't know about backslashes? How do you not know about backslashes? echo "String with a " quote"; // nope echo "String with a \" quote"; // winner

For "rare edge cases" they sure get used a lot. If you find yourself almost never using abstract classes then either you've got more code duplication going on than you know about or your codebase is designed much more vertically (long inheritance hierarchies) than it is horizontally (using polymorphism). Classes that represent some sort of functionality, and then I'd say no more than 50% of the average codebase at an extreme. Throwing around interfaces for the sake of, what, dependency injection? is as much an anti-pattern as singletons and registries.

"Abstract" is an adjective. "Class" is a noun. "Interface" is a noun. An "abstract class" is a type of class. An "interface class" is nonsense. Abstract classes and interfaces have similar purposes, yes, but there's one big difference: whether you can put code in it. Use an interface if you want a class to look a certain way but don't care how it actually goes about doing that. The power of an abstract class comes when you want more than one class to look a certain way, they'll all behave a little differently from each other, but you know there will be some code that works the same in all of them and don't want to have to repeat it everywhere. // I don't care how these classes work, but they need do specific methods in them interface IBinaryMathOperator { public function __construct($a, $b); public function getOperandA(); public function getOperandB(); public function operate(); } // most classes will behave similarly so I want to put the common code in one place abstract class BinaryMathOperator implements IBinaryMathOperator { public function __construct($a, $b) { $this->a = $b; $this->b = $b; } public function getOperandA() { return $this->a; } public function getOperandB() { return $this->b; } // don't know about this one yet public abstract function operate(); } // this class is a lot like others but does have some differences that show up in here class AdditionMathOperator extends BinaryMathOperator { public function operate() { return $this->a + $this->b; } }IMO abstract classes that don't have any code don't make sense, so don't bother thinking about them: either do an interface or add some code in it somewhere (if sensible).

The one containing the code that isn't working properly, yes.

You aren't initializing the $node variable in that one if branch.

The developer sounds stupid. Yes, at some point there is a query for the users. Either it happened for all of them when the page first loaded, or each state's users are loaded using AJAX (Javascript with a separate request to the server) when you pick a state. Easy non-dev way to check: load the page, disconnect from the internet/network, and pick a state.