requinix

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.

Threads merged and moved to Regex. terungwa, as Jacques said the regex works in PHP, while you need a pattern that works with Javascript's regular expressions (which is what the "pattern" is). There are big differences between the two. (?:\+?234|0)?(?:704|702|803|806|703|706|813|816|810|814|903|802|708|808|812|701|902|809|817|818|909|908|805|705|815|807|811|905)\d{7}- \A and \z anchors are not supported - use ^ and $. However the "pattern" is already implicitly anchored so you don't need them. - Remove the extra backslashes, which were being used for escaping within PHP strings Be sure to do the same validation in PHP (with the other regex) because this validation in HTML can by easily bypassed.

Why can't you just authenticate once for the entire duration of the script? Why does each function have to perform the same check every time?

If it needs to be private then why are you hosting the content in Google? You have a web server, possibly even a database too, so that's where it should be managed. Almost. What I'm saying is that the server cannot log into someone else's Google account. I don't think there would be a problem if the server did stuff on behalf of the owner's own Google account, but that doesn't necessarily mean there's an actual method you can use in code to login in with an email address and password. If you want the server to use your account then I suggest taking the OAuth approach too, then storing the tokens in a special "these are the owner's tokens" area (so they are not confused with those of a regular user). You'd only have to sign in once.

After you put the file someplace not accessible over the web (outside the web root is easiest, otherwise use a .htaccess with appropriate directives to deny access), make a PHP script with <?php /* do whatever you want to log access */ $file = "/path/to/file"; header("Content-Type: application/pdf"); header("Content-Length: " . filesize($file)); readfile($file);and embed the URL to that instead.

Which is another way of saying "I want the server to collect information from my Google account so it can put that information in another Google account". Either way you're trying to impersonate a user, and that's a no-no. It actually used to be a thing a while back, but they discontinued that method around... June 2014 I think? I remember that because it broke an application we were using at work and nobody knew it was coming (despite being deprecated for at least a couple years). Having the web server log in... with someone else's account. The client (user) wills in a form... containing their Google credentials. It's not an issue of being a server/client thing. It's a question of who is able to authenticate using whose account, and the answer is "only the person who owns the account". All that said, it's possible I'm misunderstanding what you're trying to do. But whatever it is, if you need to get to something in someone's Google account then you must use the OAuth process for it.

Nothing quite says "farming for answers" like copying and pasting a question from another site and not noticing it includes some of their markup. As far as I know, Google does not provide you a way to collect someone's Google account information and log into the services on their behalf. You need to use OAuth by, yes, redirecting the user to Google to approve of whatever permissions you need to do whatever actions you want. It can be a one-time action if you need access more than once, though it doesn't sound like you need that.

Does sound like a lack of focus on the application. If you use the email link then click within the page in the browser, does scrolling work?

As they said, we don't like to delete accounts around here. While you may no longer need your account, content you've contributed to the forum could be useful for other people browsing around or searching for a solution to their own problem. All you need to do is... just not use your account. No one will be offended.

I don't know. The server neither knows nor cares how the URL gets into your browser, so if you can copy/paste the URL and get different behavior then there's something wrong with your browser.

Literally nothing has changed with the software in the last... well, certainly more than a few days. Anything changed on your end? Browser? It's cliche but have you tried restarting your computer?

Ah, yeah, I misread. I was thinking curl -i -X PUT -H "Content-Type:application/json" http://localhost:8888/charts/1 -d '{"title":"My Title","xAxis":"My X Axis Title"}'or I suppose curl -i -X PUT -H "Content-Type:application/json" http://localhost:8888/charts/1 -d '{{"name":"title","value":"My Title"},{"name":"xAxis","value":"My X Axis Title"}}'I would suggest that first one: it is more typical to represent an object with key/value pairs than with a {key,value} set, and generally means less processing involved for both the client and server.

The first one is better. Note there's no particular reason why you couldn't have it support updating just one field at a time.

If I need to do a code search for anything that calls the updateName() method then the IDE won't show me that getAllowedUpdateMethods() - because "updateName" is just a string value. It doesn't know it's a method name too. Which is why PHP could benefit from a sort of ::function token like it did with ::class.

You're only checking once per day? That doesn't sound right.