requinix

[edit] You know what? Nevermind. Feeding the troll is the real detriment. ajoo, do your own research before believing one anonymous person with a fancy green nameplate on some site on the internet. And with that, I sign off from PHP Freaks until later this month when ~stuff~ will happen, because if Jacques wants to continue spreading his FUD then I don't want to be around for it.

Don't use a prepared statement. $query = "SELECT fname, lname, city, email, cell FROM staff" . ($staff > 0 ? " WHERE staff_id = " . (int)$staff : "");But what you're doing doesn't make sense. Without a staff ID, you'll pull just one random person's information out. What's the point?

I don't know your application. You're going to have to make some decisions on your own. This "status ID" thing isn't in the list of searchable terms so it sounds like you should put that condition straight into the query itself. Are you not familiar enough with SQL to know how to do that?

Either modify $where to include your condition, or write it straight into the query. Whichever makes more sense in the code.

Some people like "src" because that's traditional for compiled languages. It doesn't make as much sense for PHP, and particularly not when it's the only directory at that level. Otherwise you've got the gist of it: public/html should be the web-accessible assets and a PHP script or two, then most everything else lives outside there. Separate classes/includes/lib/logs is good.

You would have origin issues - unless you configured the server to allow cross-origin requests. You can totally do that. Is it how PHP is supposed to work? There is no "supposed". It is capable of doing many things and you are using it to do one thing. That's fine. Node.js? If you want, but that's an entirely different discussion.

But I can!

My special powers tell me that OP is in the regular ol' EST/EDT region in Canada, and where America/Toronto is the correct timezone identifier.

The code is syntactically valid. If I knew what you were trying to do with it, I would make a comment pertaining to that.

A quick adjustment to Jacques's regex: ISBN-10s can end with an X instead of the final digit, so (?[\\d-]+[Xx]?).

What you're dealing with is known as the knapsack problem. It is not trivial to solve. How large is $arr? The easiest solution will probably be to generate every possible combination of players, then filter out the ones that do not meet your team and salary requirements, then find the one with the maximum projection.

Which is it? Daylight savings or no daylight savings?

Also check the browser's console to see if there were errors or something. And check the "network" or whatever tab to see the response (if any) sent by the server, and whether it contained what you think it contained.

Sounds like OP is using "EST" as a layman's term. So

Which was... what? Please share with the rest of the class.

The only reason I can think of that someone would have the markup is because they're copying it from somewhere, and that's an instance where not being familiar with HTML causes the opposite problem. For example, Google Analytics gives you some On that note, 1. Stuff like the generator should be automatic anyways - not manually written out by someone. 2. The robots thing should be a global- or page-level option that a user enables in some configuration area, then rendered into HTML appropriately - not manually written out by someone. 3. The canonical URL should definitely be automatic - unless you want someone to be able to say that a particular page is derivative of some other page on some other website (which would be quite suspicious).

As said, that code is just plain wrong. And I too prefer the dedicated subdomain method rather than a URL prefix. That code also doesn't provide any way for a user to give their preference. Maybe they want to see the full site on their phone? Maybe you want to test out the mobile site on your desktop? Nicest method is with a cookie and putting something in the URL to switch between versions. $mobile = (isset($_COOKIE["mobile"]) ? (bool)$_COOKIE["mobile"] : $this->mobiledetect->isMobile()); $mobileurl = (strncmp($_SERVER["REQUEST_URI"], "/m/", 3) == 0); // use a ?sticky query string parameter to force the desktop/mobile site with a cookie if (isset($_GET["sticky"])) { // awkwardness to copy the session cookie parameters $params = session_get_cookie_params(); $params["lifetime"] || $params["lifetime"] = 0; $params["path"] || $params["path"] = "/"; $params["domain"] || $params["domain"] = $_SERVER["HTTP_HOST"]; setcookie("mobile", ($mobileurl ? "1" : "0"), $params["lifetime"], $params["path"], $params["domain"]); // redirect to the url without the ?sticky $query = array_diff_key($_GET, array("sticky" => 0)); $url = "http://" . $_SERVER["HTTP_HOST"] . strtok($_SERVER["REQUEST_URI"], "?") . ($query ? "?" . http_build_query($query) : ""); redirect($url); } // mobile device on a non-mobile page else if ($mobile && !$mobileurl) { $url = "http://" . $_SERVER["HTTP_HOST"] . "/m" . $_SERVER["REQUEST_URI"]; redirect($url); } // non-mobile device on a mobile page else if (!$mobile && $mobileurl) { $url = "http://" . $_SERVER["HTTP_HOST"] . substr($_SERVER["REQUEST_URI"], 2); // remove leading /m redirect($url); }then <a href="http://www.example.com/path/to/page">Desktop version that redirects to mobile if (a) a mobile device and no cookie or (b) mobile=1 cookie</a> <a href="http://www.example.com/m/path/to/page">Mobile version that redirects to desktop if (a) a non-mobile device and no cookie or (b) mobile=0 cookie</a> <a href="http://www.example.com/path/to/page?sticky">Desktop version and sets a mobile=0 cookie</a> <a href="http://www.example.com/m/path/to/page?sticky">Mobile version and sets a mobile=1 cookie</a>

DTD, XSD, or Relax NG schema validation could do a lot of work, but AFAIK wouldn't be able to validate actual attribute values (eg, that the canonical URL has the right domain). That basically leaves you with your own validation routines. As long as you approach it like a whitelist - specifically allow certain structures, disallow everything else - then this is quite possible. However it gets exponentially more difficult as you allow more complex HTML; just that example there would be fine, but I'm more concerned about what else would be possible. Unless you want to get really sophisticated with this, you should do the specific key/value meta pairs thing (and a separate entry for the canonical URL, plus whatever else). It's the safest course of action, and it doesn't require that the user understand writing HTML markup. As a secondary option for the user, you could allow them to input HTML and then scan it for particular elements to keep. As in load the string into DOMDocument (no regular expressions), search for and tags, then extract the data into that key/value system. I could write a proof of concept for the "sophisticated" approach, if someone asks for it, but I just started playing FFXIV and right now I'd rather do that.

Really tired of people wanting arrays over objects... Look. $xml = new SimpleXMLElement("/path_to_file/file.xml", 0, true); // or simplexml_load_file if you insist foreach ($xml->row as $row) { echo "{$row->name} is {$row->age} years old<br>\n"; } See how easy that was? As for the actual problem, try it out on a regular array (which has the same problem that objects do). echo "<pre>"; print_r(object2array(array("name" => "Happy", "age" => 20))); echo "</pre>";Now try to understand what it is doing:1. Is $object an array? Yes. foreach over it and call object2array on each member. 2. Is $object["name"] an array? No. Call get_object_vars on it, see that the return value is no good, and call strval. 3. Is $object["age"] an array? No. Call get_object_vars on it, see that the return value is no good, and call strval. It's assuming that every single value nested within the $object is either an object or array. And that's not necessarily - or even likely to be - true. It needs to check a) if $object is an array, or b) if $object is an object, or otherwise c) it's neither. But don't do that. Just use SimpleXML like it's supposed to be used. Objects aren't scary. They won't bite.

Current best practice, one I happen to quite dislike, is to use responsive design for your website: make it work on both desktop, tablet, and mobile devices by using CSS to affect what people see based on their device. For example, on a desktop (which has a large screen) most or all of the page appears normally, but on a phone (which has a small screen) some parts are hidden or otherwise altered so they appear differently. That results in one website running one set of PHP scripts with no URL rewriting necessary. Besides that there are two tactics: 1. Using a bit of Javascript on the client to detect the device and automatically redirect to the other version of the website if the user landed on the wrong one and has not explicitly opted to view the other one (typically involving setting and checking for a cookie). 2. Do user-agent detection on the PHP side to perform a similar redirect. #1 is the better of the two. There are other concerns too: - Search engines will penalize you for showing duplicate content at two different URLs. You need to use canonical URLs to indicate on the mobile site that the desktop site is the original source. - If you use any sort of redirect then you should pick one as the "normal" site and always link to that. It's not so much a technical thing as it is ensuring that you treat your website as two different views of the same content, rather than as two different websites. Mobile users landing on the desktop site will be redirected so there's no problem there.

There is nothing in the root .htaccess that redirects to mobile, so either you're clicking a link to /m/something or your PHP code is doing the redirect.

The RewriteRule is pretty straightforward (replace /data/X/Y with /data/X/medium/Y), so the "hotlinking" portion you're missing is the RewriteCond immediately preceding it. RewriteCond %{HTTP_REFERER} !^https?://blah\.com(/|$)But... are you creating actual directories there? That's really not the right way to do things. There's no problem making it look like there's directories there, but on the server there should most definitely not be tons of directories in /data. For a variety of reasons, not least plummeting performance the more you make.

If the list has only constant values then it will be sorted and MySQL will do a binary search (->). That's one additional comparison every time you double the size of the list. While not a big difference, I'd remove them: one pass in PHP to remove vs. however-many additional comparisons in MySQL.

Hold on a second. Are you saying that one of those works perfectly(ish) for you except for the fact that it needs "plain HTML data"? Because PHP is perfectly capable of generating said HTML data (even without displaying it), which could then be fed into one of those methods.

I didn't follow that. You do OAuth using your personal account, you allow Google to grant your application access to the Drive data, then the server gets a token which it can use to do stuff with Drive. Yes, but you're getting to a place where you need to start learning about how OAuth works. In your application (using your browser) you do some specific action which initiates the OAuth process. After being redirected to Google and back to the server, it will have a token that is good for some period of time (which IIRC can be extended programmatically as needed). That token goes into a special place because it's a token for your account - not just some regular user's. Right. I reiterate my point about you not storing stuff in Drive this way. Yes. More than one, but using PHP code. Uh... Google? "google oauth" should take you exactly where you need to go. You may need to specifically learn about OAuth itself - how it works and such - for Google's docs to make enough sense. It should be easier now that you know what you need to look for; if searching for how to log into Google programmatically found any results, they'd all be old and useless by now.