requinix

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.

"Really simple and optimized" isn't going to do it there. Uptime for a particular service (like a web server) is measured by when the service is accessible. To monitor the service yourself you're going to need something that can evaluate the status of the service. For example, with a web server you'll need something to "ping" the server periodically. Such as a cron job on a one minute timer. When it connects successfully the service is "up", and when it does not the service is "down". Recording that information could go any number of ways. Times 100-200 is not going to be simple, because connecting to that many services could easily take more time than you have between measurements. So that means either multiple "machines" measuring uptime or relaxing your measurement interval. Off hand, one way to store the results is to stick a record in the database per service per minute indicating whether it's online, then using a periodic (daily, weekly) job to summarize that information. Such as calculating uptime for a particular interval, and probably removing the individual measurements for the sake of storage. Or another method would be to say that each per-minute online measurement affords 1 units of uptime (and each day is, eg, 1440 units long), and you can simply accumulate units for each interval: INSERT INTO uptime (machine, service, day, uptime) VALUES (DATE(), 1) ON DUPLICATE KEYS UPDATE uptime = uptime + 1(where the machine+service+day is a unique key and you count uptime as 1=online and 0=offline)

It may be because I'm drunk ( ) but I don't understand what you're asking. Do you want to chart the server's uptime over a period of a week? Does the output from `uptime` help?

Your new server doesn't have short_open_tag enabled. Best practice is to use the full "<?php" so the changes you made were a good thing.

I'm not a fan of putting function or method names in strings (IDEs can't recognize them). And I'm not a fan of conventions like calling "update"+Name methods (too magical for my tastes). I'd still go with the "configuration"-type approach. Unanswered question that would help to be answered: What ways of handling values are there? For example, there's those three types from earlier: #1 was updating a column in a table, don't know about #2 and #3. I ask because my next thought is abstract class Chart { private $fields; public function __construct() { $this->fields = $this->getFields(); } protected function getFields() { return array( "name" => new UpdateType1("name", $this->id, $this->account->id), "title" => new UpdateType2(...), "subtitle" => new UpdateType2(...) ); } public function set($name, $value) { if (isset($this->fields[$name])) { $this->fields[$name]->update($value); } else { error } } } class BarChart extends Chart { protected function getFields() { return array_merge(parent::getFields(), array( "xAxis" => new UpdateType3(...), "yAxis" => new UpdateType3(...) )); } } interface IUpdateType { public function update($value); } class UpdateType1 implements IUpdateType { private $field; private $id; private $accountid; public function __construct($field, $id, $accountid) { $this->field = $field; $this->id = $id; $this->accountid = $accountid; } public function update($value) { // update database } } I forget the name of this design pattern. It's similar to Command.

Do you have to use subclasses? class Chart { private $type; private static $CHARTS = array( "bar" => array("xAxis", "yAxis"), "pie" => array(/* what do you need in a pie chart? */) ); public function set($name, $value) { if ($name == "name") { // all charts have a name // update database } else if ($name == "title" || $name == "subtitle") { // all charts have a title and subtitle // ??? } else if (in_array($name, self::$CHARTS[$this->type])) { // ??? ] } } $chart = new Chart(whatever, "bar"); $chart->set($_POST["attrName"], $_POST["value"]); Sure, you could go the OOP route, but it's making this unnecessarily complicated when all the subclasses do (?) is indicate available field names.