requinix

The dates are stored in data, which is actually an array of dates so I don't know what you'd want to do if it returns more than one set of dates (if that's possible). data[0].qstartDate data[0].qendDate

I can't tell if you actually assigned values to all those variables. You have something that outputs an error in case of failure. Did it output an error? What did it say?

Your question was "This site has PSN codes that [look like they] change every time. How do I make those codes?" Your question was not "This site distributes PSN codes. I want to do that too. Here is how I plan to get the codes and how I want to offer them to the users: [...]. How do I do that?" You have codes. Two things come first: 1. Store those codes in a database. You'll need to know the code, the amount, and whether it's been used. You'll probably want to track other information like the IP address of the person who claimed it, when they claimed it, maybe a SKU or barcode or whatever of the actual product you bought (for record-keeping), etc. 2. Build some way for you to enter new codes. If you already have an admin-type area on your site, that would be a great place. You'll want to add new codes as well as look at existing codes, check usage, and maybe create some reports like how many have been used and by whom. As for the way for a user to get those codes, how are you going to offer (aka subsidize) them? Referral programs? Whose? Or do something else?

Yeah, that's not how PSN codes work. Your site would have to buy the codes (from wherever) and then... what do you want to do, just give them away? These sites do it by using advertising and affiliate programs to recoup the money spent. It's not free.

The relevant bit in there is either function topic($data, $forum_data, $other_data, $inforum) { $topicc = IPSMember::load( $data['starter_id'] ); $lastp = IPSMember::load( $data['last_poster_id'] ); $starter = IPSMember::makeNameFormatted( $data['starter_name'], $topicc['member_group_id'] ); $lastposter = IPSMember::makeNameFormatted( $data['last_poster_name'], $lastp['member_group_id'] ); $data['starter'] = IPSMember::makeProfileLink($starter , $data['starter_id'] , $topicc['members_seo_name']); $data['last_poster'] = IPSMember::makeProfileLink($lastposter, $data['last_poster_id'], $lastposter['members_seo_name']); return parent::topic($data, $forum_data, $other_data, $inforum); }or function asForumTopics($data) { $topicc = IPSMember::load( $data['starter_id'] ); $lastp = IPSMember::load( $data['last_poster_id'] ); $starter = $this->caches['group_cache'][ $topicc['member_group_id'] ]['prefix'].$data['starter_name'].$this->caches['group_cache'][ $topicc['member_group_id'] ]['suffix']; $lastposter = $this->caches['group_cache'][ $lastp['member_group_id'] ]['prefix'].$data['last_poster_name'].$this->caches['group_cache'][ $lastp['member_group_id'] ]['suffix']; $data['starter'] = IPSMember::makeProfileLink($starter , $data['starter_id'] , $topicc['members_seo_name']); $data['last_poster'] = IPSMember::makeProfileLink($lastposter, $data['last_poster_id'], $lastposter['members_seo_name']); return parent::asForumTopics($data); }I don't know whether you made any changes to the plugin so I won't comment on that, but the two lines involving $lastposter $data['last_poster'] = IPSMember::makeProfileLink($lastposter, $data['last_poster_id'], $lastposter['members_seo_name']);(both identical) are definitely incorrect. $lastposter is always a string (a display name) so $lastposter['members_seo_name'] will not work. They should be using $lastp instead as that's the array of information about a user. $data['last_poster'] = IPSMember::makeProfileLink($lastposter, $data['last_poster_id'], $lastp['members_seo_name']);

I would think a simple '//script[@src="http://www.mar.com/network/abc.js"][@async]'should work fine.

Use code tags when posting code (or stuff like that PHP output). I've done it for you this time, please do it yourself next time. Assuming you're using mysqli, take a look at the documentation for examples on how to call stored procedures. If you aren't, the process and code will likely be very similar.

Here's something that should work a little better. 1. Rewrite all requests to directories to go to your indexing script. RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ my-awesome-php-script.php [L]2a. Theoretically, as long as you don't do anything more complicated than that, the DOCUMENT_ROOT + REQUEST_URI will be the directory requested. In practice it might not be - it could be my-awesome-php-script.php itself, for example. So $path = $_SERVER["DOCUMENT_ROOT"] . $_SERVER["REQUEST_URI"]; if (!is_dir($path)) { // invalid path } // show files in the $path directory2b. It's possible someone could somehow (don't worry about trying to imagine exactly how they do it) manipulate the path you check. This is where you deal with . and .. and then make sure that the final resulting path is allowed. Easiest way is to work with just the REQUEST_URI by replacing /./ with / (string replacing can do this), as well as replacing /foo/../ with just / (regular expressions will make that much easier) and then making sure there aren't any ..s left in place.3. After step 2, let's say you have $requesturi = "/" . trim($_SERVER["REQUEST_URI"], "\\/") . "/"; // clean up slashes $requesturi = str_replace("\\", "/", $requesturi); // windows' slashes -> regular slashes $requesturi = str_replace("/./", "/", $requesturi); // remove . components $requesturi = preg_replace('#/[^/]+((?R)+|/)\.\./#', '/', $requesturi); // recursively remove .. components $requesturi = preg_replace('#//+#', '/', $requesturi); // repeated slashes // if there are any more ..s then the path is trying to go above the DOCUMENT_ROOT if (strpos($requesturi, "/../") !== false) { // invalid path } // the path is relative to the DOCUMENT_ROOT $path = rtrim($_SERVER["DOCUMENT_ROOT"], "\\/") . $requesturi; if (!is_dir($path)) { // invalid path } // show files in the $path directory The "base" directory is according to the REQUEST_URI (which was cleaned up to $requesturi) and you would use this when constructing links. foreach (scandir($path) as $file) { $filepath = $path . $file; $uripath = $requesturi . $file . (is_dir($filepath) ? "/" : ""); // trailing slash. not required but helps distinguish files vs directories [code] If you gave listings for . and .. then they should get special treatment: don't show .. in the root directory, leave the link alone for just ., and remove a directory for .. (All the code is untested but should be at least close to accurate.)

Yes, but you should do a bit more than that. Like validate the path: make sure it doesn't go places you don't want it to go (like via a "../"), and make sure the path exists before trying to call scandir() because that's the polite thing to do. And to be honest, $num_items = 3; $split_uri = explode( "/", $uri, $num_items ); $uri = "./" . $split_uri[ $num_items - 1 ];that bothers me. Why 3? What were the two items before it? Will those change? Can you just use $_GET or even the entire query string instead?

The REQUEST_URI is the raw URL sent. Spaces will be encoded as %20 (and other characters will be encoded too). So you'll need to decode it before you can use it.

I feel iffy about making changes to $_GET and $_POST. How about making a copy and modifying that instead?

Complex refactoring rituals would still happen. They could be used to increase the efficiency of code, even if not to make it easier to read. Design patterns would still exist. A design pattern is simply a common solution to a problem. They aren't necessarily object-oriented. Frameworks would still exist. They're to save time in development not having to reinvent the wheel. Application stacks would still exist. They're combinations of software so as long as software exists, they will too. "Refactoring" is merely rewriting with the intent to somehow improve the code. Improvement in maintainability is one possibility. Improvement in efficiency is another. Those are are often mutually exclusive. Code that looks horrible means that it will be harder to alter. I'm half-asleep.

First, what version of PHP are you using? If it's not at least 5.4 then can you upgrade to at least 5.6?

That'd be fine. While websites should definitely update the expiration time, APIs are a little more flexible. You could enforce a hard limit of X minutes on just the API if you expect whatever operations (eg, with the mobile app) will last much less than that time. However once that time is up the user will have to log in again; the app could keep the username and password in memory (it really shouldn't if at all possible) but otherwise the user would need to type the information in again. So yeah, updating is fine. The latter (setting a flag) is probably fine for the site. It's more of a technical question: would the site actually need to use the token later? You could impose a security layer within the stored procedures such that "sensitive" operations require a token before they can perform any action. For example, changing a password could require a username, password, and token, where it uses the token (after validating it, of course) to identify the user performing the update and checks whether that user is allowed to do so: if the token corresponds to that user or to a particular sort of administrative user that is allowed to change passwords then update the password, else fail. The API would work differently since APIs don't really use sessions. I mean you could, but then you force the consumer to deal with cookies and that can suck. If you decide against the added security then your API would be the one that validates the token (via a stored procedure) and does the update. Questions are good. There should never come a point in your life where you don't have questions to ask. About anything. It would be nice if other people reading this thread commented too, though.

If you don't mind PHP evaluating up to 800 conditions to get the value of a single variable, sure.

IS NULL is how you check whether a value is actually NULL or not. You will get true/1 or false/0. = NULL is normal comparison, except when you compare something with NULL you will simply get NULL as the result. Try it: SELECT 1 IS NULL; SELECT 0 IS NULL; SELECT NULL IS NULL; SELECT 1 = NULL; SELECT 0 = NULL; SELECT NULL = NULL;

Floating-point arithmetic Round your calculations but only at the very end.

Depends what you mean by "the site". The PHP code behind your site will not use it, but the AJAX and Javascript on your site will - that's how it communicates with the server. The mobile app would use it too.Basically it comes down to whether the thing is running on your server (PHP code) or not (AJAX runs on the browser, mobile app runs on mobile). ...Maybe? I don't think I understand what you're saying. You're developing a site which includes a user login component. The external API is /api/users/login and is the only way code that is not running on your actual server can interact with the server. So AJAX and third-parties would use it. (For all intensive porpoises your mobile app is "third-party" because it's not running on your server - you just happen to be its developer too.) The internal API is what the stuff that is running on your actual server, as in the actual PHP code, interacts with. Or I guess put another way, consider what the code for /api/users/login would look like. You receive some input (GET, POST, whatever), somehow get that to your stored procedure, receive the token, and return it however you'd like as output. The question is exactly what the "somehow get that to your stored procedure" is. Obviously your code needs some way to communicate with the database, but it could do so directly (by setting up a database connection, binding parameters, and executing SQL) or indirectly (by calling other code which communicates with the database). If you do it directly then that's alright. If you do it indirectly then whatever you use there to fill in the gap would be the internal API. Directly: <?php // /api/users/login $email = $_POST["email"]; $password = $_POST["password"]; // this example here uses output parameters from the proc. yours simply returns a resultset $connection = new mysqli_or_pdo_or_whatever(/* parameters */); $query = $connection->create_a_statement_for_the_stored_procedure(); $query->bind_the_parameters_to_the_query($email, $password, $variable_to_receive_the_token); $query->execute(); return json_encode(array( "token" => $variable_to_receive_the_token ));Indirectly with an internal API. <?php // /api/users/login $email = $_POST["email"]; $password = $_POST["password"]; $user = User::login($email, $password); // User::login will somehow, directly or indirectly (via yet another internal API), communicate with the database to log in return json_encode(array( "token" => $user->token ));The internal API has a number of advantages, most notable being:- Much less code - The exact mechanism of how to log in are abstracted away and the /api/users/login doesn't need to know them - The mechanism can change so long as the API ("provide me with an email and password and I will return you a User object") looks the same Therein lies a problem with your API. Or rather, the code you have in place to perform the work for your API. Yes, you are correct in that it is like an internal API. Except it has too much knowledge about how it's being called: the information is coming from a request, it knows the parameters are called "username" and "password", and it outputs JSON according to the result. You won't be able to reuse that anywhere and reusability is a big principle behind an API - internal or external. What you should do is split it apart into two pieces: one to receive data from the request and send whatever output, another to handle just the login. // this function can handle a login that originates anywhere // it returns an array in a specific format that is independent of how the calling code needs to react function loginUser($username, $password) { try { $sql = "CALL checkPassword(:username, :password)"; $dbCon = getConnection(); $stmt = $dbCon->prepare($sql); $stmt->bindParam("username", $username); $stmt->bindParam("password", $password); $stmt->execute(); $result = $stmt->fetchAll(); return array( "loggedin" => $result[0]["loggedin"], "uid" => $result[0]["uid"], "firstname" => $result[0]["firstname"], "token" => $result[0]["token"], "potentially" => $result[0]["field1"], "other" => $result[0]["field2"], "useful" => $result[0]["field3"], "data" => $result[0]["field4"] ); } catch (PDOException $e) { // calling code should not need to know about PDOException or anything specific like that // wrap this into a more general exception throw new loginUserException("Failed to log in", 0, $e); } } // this function can handle a login but only if the information comes from the request in // a specific format and only if the response can be JSON in a specific format function loginUserFromRequest() { global $app; $req = $app->request(); $paramUsername = $req->params("username"); $paramPassword = $req->params("password"); try { $return = loginUser($paramUsername, $paramPassword); // the function returns an array with a lot of stuff. we only care about some of it echo json_encode(array( "uid" => $return["uid"], "loggedin" => $return["loggedin"], "firstname" => $return["firstname"], "token" => $return["token"] )); } catch (loginUserException $lue) { echo json_encode(array( "error" => array( // notice that this will always say "Failed to log in" // never expose database error messages! "text" => $lue->getMessage() ) )); } }loginUserFromRequest() is a mere function, but provides the backbone for the /api/users/login external API. In an MVC architecture, it is your controller (and view).loginUser() is an internal API and provides the backbone for other code in your application to log a user in. You can reuse it anywhere that you have a username and password. loginprocess.php would have code that resembles loginUserFromRequest() in that it gets the username and password from the request, passes it to loginUser(), receives the result, and displays something to the user. Let me turn the question around on you: is the site in a state where you can leave it alone? If so, feel free to focus on the external API. You'll probably end up refactoring parts of the site as you go anyways. But if there is something wrong with the site and it's in a state where you shouldn't leave it alone and go work on something else, then... well, there's your answer.

There are two main types of APIs and I think this may be confusing you: 1. An external API, like the kind you would put at a URL like /api/users/login. Javascript/AJAX on your site can call it, other third-party services can call it. Your PHP does not call it. This API is not necessary for a "traditional" site where you have a POSTed login form, but is important if you want to use AJAX (or let other people call your API). 2. An internal API. This isn't accessible by anything but your own PHP code. Your stored procedure to login is an example of this: it provides an interface between "you" (your PHP code) and "the service" (the user login data in the database.) If you wrote some generic code to call it, as in some User class with a login() method, that itself would be a sort of API because it is the interface between "you" (other PHP code across the site, like the code for loginprocess.php) and "the service" (whatever thing is in place that deals with logging users in). The API you have now that returns JSON is fine. The login token is fine; I suggest some mechanism to refresh a token, however, or else people will be forced to log in every X minutes regardless of whether they were active or not. (You can refresh on a hit to an API and on a page load on the site.) Unless you're talking about a "remember me"-type token which is used to log someone in automatically, but your description doesn't quite sound like that. Your PHP does *not* use the external API, and this is where those two types of APIs come into play. If your PHP used it, it would have to call a page on its own website, which would execute code elsewhere in parallel, and after all is said and done you've created a lot of needless work for your code and your server. What you should do is create the internal API. This is the code that connects to the database, runs the stored procedure, and returns whatever information. It will have two consumers: loginprocess.php calls it when someone submits the form, and the /api/users/login API calls it when someone invokes it. Thus the two execution flows are 'user -> submits login form on website -> loginprocess.php -> internal API --+ | v database | redirect user or whatever <- loginprocess.php <- internal API <-+' ' login page -> AJAX -> /api/users/login -> internal API --+ | v database | JS reacts <- response <- /api/users/login <- internal API <-+'

Automatic refresh means refresh the page. Load it from scratch. F5. Doesn't know anything about new data because it loads everything all over again. So... is that still sufficient? Add a to your HTML output, replacing number with how many seconds you want it to wait before refreshing.

Look at the line above to see if there's something wrong with it.

It has been removed with PHP 7.

Would it be sufficient to simply refresh the page every few seconds? Automatically, that is.

Shh.

Where's the Dislike This button?