kicken

I'd use sha1 and something related to the user rather than the IP (their email, the User ID, whatever). You'll also want to ensure generated tokens expire after a given time frame and after they have been used. That would probably be "good enough." If you want something more random, then use a better random source such as openssl_random_pseudo_bytes, random_bytes(PHP 7, but there is a shim available for older versions), or mcrypt_create_iv. With those you'd get pure random string of bytes, which you can then either hash or hex-encode to form your token.

When you save the data to the database, also include a column set to the current time. Then when you display data, only display data that was added <= NOW() - 48 hours

You do not need to include the email address in the link, just the the token. You'd search the DB for the token when the click the link then you can get the email address and other data from there. Other than that, sending a token is a fairly standard way of letting someone confirm their email address. Just make sure the only thing you do with the token is mark the account active. Don't have it auto-login the user after activation and don't show any personal data on the activation page.

You need echo or return. Such as: <?php function headerInfo(){ return <<<HEREDOC ... HEREDOC; } ?> ... <?php echo headerInfo(); ?> or <?php function headerInfo(){ echo <<<HEREDOC ... HEREDOC; } ?> ... <?php headerInfo(); ?> Your posts up until now included neither. Note that you don't need to use a HEREDOC at all. You can just exit PHP mode, dump your HTML, then re-enter PHP mode and end the function. I personally find that to be cleaner when dealing with large chunks of HTML, and it sometimes works better with editors tools. <?php function headerInfo(){ ?> ... html here ... <?php } /* End function headerInfo */ ?>

I've been using Symfony and Doctrine ORM for a while now, and over all I've found the ORM stuff to be alright. It certainly did take a while to get used to after having used DIY querying for years though. The ORM doesn't completely remove the need to do your own SQL queries, but it does help with removing the need to do some of the more basic DB work. It helps you to keep your data management in PHP rather than having to mess with a bunch of queries for simple things. For example, adding a new record is as simple as doing something like: $u = new User('kicken'); $u->setRegisteredOn(new DateTime())->setStatus('active'); $orm->persist($u); $orm->flush(); Much nicer than having to deal with generating the appropriate SQL, do the parameter binding, etc. Fetching / Updating / Deleting data is similarly simplified. Using an ORM isn't a "never write SQL again" mode though. While it helps remove a lot of the simple/boilerplate type stuff, for more advanced querying you'll likely still be writing your own queries and handling results manually. For example when building reporting tools or advanced searching/filtering of data. I've found that in a lot of my projects at least, most of the time I'm dealing with data in ways where the ORM features work just fine and I can avoid having to deal with custom SQL. Typically I'm working directly with specific entities and can load them by their ID or by a simple search (eg, by name). Rarely do I find that I have to create custom queries for data, usually the custom queries are only needed some specific instances (which tend to overlap) such as: Generating complex reports Complex filtering of data Dealing with massive amounts of data In those situations there can often be a more optimized way to query for the data than what the ORM system would do. For example if your accessing a bunch of records for a report, the ORM may run out of memory by trying to load the entire result set and all the data for each record. By querying yourself you can easily limit the results to only the columns you need and process results as they come. Of course I can't say much as to what the rest of the web is doing with there systems, but I would imagine that most applications have some kind of ORM-like setup that lets them worry less about the SQL and focus more on the data. That is mostly the point of ORM systems, focus on the data and your code and less on how to talk to the database about the data.

In addition to the above, ultimately it's up to the company to ensure a password is either not lost or can be recovered. For example by registering under an alias email which they can then forward to whoever is in charge at the time. If that person leaves without providing the current password, they can just change their email forward to a new employee and use the normal forgot password process. Of course you'll want to also provide some means of initiating a reset via support channels. You'll have to develop some policy for determining that the person contacting support is authorized to reset the password, then send a reset link to a provided email address.

If you can fit it into a column then it'll be fine. I wouldn't worry about the length of the data, just how it's used. In the situation you describe, I would normalize it out into separate tables, not because a building may have 1000 data points, but because it seems likely to me that you would want to (if not now, in the future) do work with the individual data points. For example, what if you decided to keep a history of data so you could track changes over time? With just single json column, it would constantly grow in size as data was captured, likely exceeding the limit of the column's data type eventually. Trying to find data for a particular time (ie, most recent data) would also be overly complicated. As you also mentioned, what if you want to see just the current temperature of each building? Not easily done with just SQL, and even with PHP you'd waste a lot of resources passing back huge json strings just to extract a single number. When I store simple json (or whatever) strings it's usually more of configuration type thing. For example in one application with a customizable menu system I stored individual menu item configurations as a simple json string. Each menu item could be of various types, each of with required different parameters. There was never any need to query these parameters individually. If such a requirement had existed, then having another key/value table for the configuration would have been appropriate.

You most likely have your developer tools configured to stop on all errors. During a normal run that error would be caught by the try{} block and ignored. That function is testing to see if the browser supports using createElement with a full tag. The standards compliant way to use createElement is to specify only the tag name, such as: document.createElement('input'); To get IE to ignore it while debugging you need to change the exception behavior. There is a button for this in the toolbar that looks a bit like a stop sign. Shortcut is ctrl+shift+e.

Store the result of your query into an array rather than printing it immediately. Then you can check if the array length is 0 or not before displaying the results. $data = []; while(db2_fetch_row($queryexe)) { $data[] = [ 'HSSESN' => db2_result($queryexe, 'HSSESN'), // System Name 'HSLOGI' => db2_result($queryexe, 'HSLOGI'), // System Roll 'HSRETN' => db2_result($queryexe, 'HSRETN'), // System Ping 'HSDATE' => db2_result($queryexe, 'HSDATE'), // System Maintenance 'HSTIME' => db2_result($queryexe, 'HSTIME'), // System Telnet Status 'HSTEXT' => db2_result($queryexe, 'HSTEXT') // System FTP Status ]; } if (count($data) == 0){ echo "No results"; } else { //Show results }

I just threw an accesskey attribute on a random link on my site and gave it a try in Edge and had no issues with it. Do you do any key-capturing with javascript that might be causing an issue in Edge?

it's America/New_York, with an underscore not a space.

Usually if adding an alert fixes a problem it is due to a race condition. Most likely in this case, the browser is firing the event and your code is running before it updated it's state with the new width and height information. You can work around it by wrapping the function in a timeout to delay it while the browser updates it's state. Alternatively, have you tried using the resize event rather than the orientation event? I think that would be more appropriate as it would also handle cases on a desktop of the user just resizing their browser window. //cache $(window) to save some function calls. var $window = $(window); $window.on("resize",function(){ $('div.myDia1').dialog( "option", "width", $window.width()-25); $('div.myDia1').dialog( "option", "height", $window.height()-25 ); });

I'm not familiar enough with nginx to know if it has a built in solution to your problem, but if it doesn't, then an alternative is to use some sort of build and template system outside of nginx to generate the configuration file. For example, you could use a simple PHP script and the Twig template engine to run through a list of domains and generate individual configuration files for each domain based on a standard default template. Whenever you need to make a change, you alter the template then re-generate the configuration files by running the PHP script and then reload nginx.

A basic rule of thumb is if you ever need to do something such as search for a particular value within the list, then you normalize it into it's own table with one value per row. If you only ever work with the data as a whole, then usually storing it as a single value will work ok. I tend to prefer storing a JSON structure rater than a simple list, but either way would work fine.

Your value is an DateTime object, not an array. The keys it shows when you run it through print_r / var_dump do not actually exist, they just show for debugging. To get a string version of the date, you need to call the format method. Also, you need to quote your array key names. For example: $dateString = $aContactToImport['LastUpdate']->format('Y-m-d H:i:s');

You should not be using the mssql_* functions. They have been deprecated for a while, and removed in PHP 7. MSSQL Extension

Most likely someone was testing your server to see if it would operate as an open proxy by requesting a full URL rather than just a path on your site. For example, sending a request like: GET http://www.example.com/ HTTP/1.1

I was starting to wonder if the site was just down for good this time. Will be interesting to see what happens with the owner change, I'll have to check in more often.

PHP The Right Way is a good start. There is a lot of good information there.

I use Twilio for a couple small things and have been pleased with the service. I just use the $1 local numbers, not the short codes. Near as I can tell from a little googling it costs $500/month for a random short code to be assigned to you, then it has to be submitted to the various carriers and they will determine if they want to support it or not on their network. Twilio seems to add an extra $500 on top and manages the process for you. You might be able to find cheaper if you shop around, but almost certainly no less than $500/month for a random number since that's the base registration cost (similar to how domain registration works).

The .val() method will give you the value of the input, regardless of whether it was set by code or typed in by the user. If you're adding any number formatting to the cost such as commas or dollar signs then you'll need to remove that formatting before reading the value out and trying to use it to calculate the total. You'll also need to reset your runningTotal to zero each time before trying to calculate the total. Other than missing this, your code looks fine as is. Your code works fine with the runningTotal reset and fixing the syntax problems (assuming copy/paste error). See the fiddle When you post code try and make sure it's syntatically correct/complete. Also it helps if you describe why you think something isn't working rather than just saying what you think the problem is. What did you think that .val() was not working to get the computed values? What kind of problem were you seeing?

Create a page which calls the phpinfo() function. It will tell you how PHP is configured with apache. Look for the row beginning with Server API and see what it's value is. My server for example is setup to use FPM with FastCGI and show FPM/FastCGI as the server API. I'm not sure exactly what other setups would show, as it's been a long time since I used any other configuration.

Based on the example you gave, I see no reason to create a helper method on the parent class. The deleteFoo and deleteBar methods are part of the same child class, so just make the helper a private method there. As far as being able to add arbitrary code at the sccess branch, one thing you can do is use a callback method. <?php class childController extends parentController { public function deleteFooDocument(){$this->deleteDocumentHelper('foo');} public function deleteBarDocument(){ $this->deleteDocumentHelper('bar', function($doc_id, $id){ $this->getModel()->updateParentAudit($this->audit_table, $id); }); } private function deleteDocumentHelper($type, $successCallback=null){ if(isset($_POST['id'],$_POST['doc_id'])){ if(documents::removeDocument($type,$_POST['doc_id'],$_POST['id'])) { $success=1; //Ability to replace the following line with one or more lines if ($successCallback){ $successCallback($_POST['doc_id'], $_POST['id']); } } else {$success=0;} header('Content-Type: application/json;'); $this->dontCache(); echo(json_encode(array('success'=>$success))); } else {exit($this->missingPage());} } } ?> Alternativly you could use a couple separate helper methods, but keep the if branch for the delete in the controller. <?php class childController extends parentController { public function deleteFooDocument(){ $this->checkExists(); $success = documents::removeDocument('foo',$_POST['doc_id'],$_POST['id']); $this->outputResponse($success); } public function deleteBarDocument(){ $this->checkExists(); $success = documents::removeDocument('bar',$_POST['doc_id'],$_POST['id']); if ($success){ $this->getModel()->updateParentAudit($this->audit_table, $_POST['id']); } $this->outputResponse($success); } private function checkExists(){ if (!isset($_POST['id'], $_POST['doc_id'])){ exit($this->missingPage()); } } private function outputResponse($success){ header('Content-Type: application/json;'); $this->dontCache(); echo(json_encode(array('success'=>$success))); } } ?>

_doSomething would be fine. I'm not a fan of underscore prefixing methods personally, but that's just my own personal style. If possible I would give it a more meaningful name name than doSomethingInternal() even, but that would require knowing more about what the method does. The doSomething is defined as being abstract which means a few things. It is unimplemented. The method is defined, but has no known implementation yet so it cannot have a body. If a class has an abstract method, it itself must be defined as abstract. This prevents anyone from doing new ParentController() in the code. Any child classes must either implement that method, or declare themselves to be abstract. So in order to do new ChildController1, ChildController1 must implement the doSomething method. The success() and failure() methods are defined as simple empty methods. This means the child classes can override them and implement a specific behaviour, but they are not required too (unlike if they were abstract). getExtra() is defined as abstract so each child class must define that method. What I forgot to do in the example was change doSomething() to call success or failure rather than return $flag. The do something method would look more like: protected function doSomething(){ header('Content-Type: application/json;'); $id=(isset($_POST['id']))?$_POST['id']:0; $other=new otherclass(); $x=$other->bla($id,$this->getExtra()); $flag=$x['flag']; unset($x['flag']); echo(json_encode($x)); if ($flag){ $this->success(); } else { $this->failure(); } }

It's generally considered bad to override a method and change it's parameter signature. This is why PHP throws a strict standards warning if you do so. The reason behind this is that it makes the child classes incompatible with the parent, and thus they couldn't reliable be used with something that might written to specifications of the parent class. For example, what if you had some service that expects a ParentController object and tried called the doSomething() method. That code would assume that the function accepts an argument and does something with it. If you passed one of your child controller instances, the argument would be ignored. In your particular case this is not as much of an issue, but it's still a poor habit to get into. Think about if instead of reducing the parameter list you tried to extend it with non-optional parameters. Then the service would generate errors when calling the function because it didn't pass enough arguments. The better solution is to use an abstract (or empty implementation) method as the entry point which the child classes can then override. Any code that should be shared would then be moved out to another separate method which the children can then call when appropriate. <?php $controller=new ChildController1(); $controller->doSomething(); abstract class ParentController { abstract public function doSomething(); protected function doSomethingInternal($extra){ header('Content-Type: application/json;'); $id=(isset($_POST['id']))?$_POST['id']:0; $other=new otherclass(); $x=$other->bla($id,$extra); $flag=$x['flag']; unset($x['flag']); echo(json_encode($x)); return $flag; } } class ChildController1 extends ParentController { public function doSomething(){ if($this->doSomethingInternal('usethis1')){ $this->bla_a(); } } } class ChildController2 extends ParentController { public function doSomething(){ if($this->doSomethingInternal('usethis2')){ $this->bla_b(); } } } As also mentioned, if the pattern of 'if doSomething then bla();' is common across several children, you can move that up to the parent and just have the child classes override the bla method. Something like this: abstract class ParentController { abstract protected function getExtra(); public function success(){} public function failure(){} protected function doSomething(){ header('Content-Type: application/json;'); $id=(isset($_POST['id']))?$_POST['id']:0; $other=new otherclass(); $x=$other->bla($id,$this->getExtra()); $flag=$x['flag']; unset($x['flag']); echo(json_encode($x)); return $flag; } } class ChildController1 extends ParentController { protected function getExtra(){ return 'usethis1'; } public function success(){ //Rather than call a method, you'd just put your logic here directly $this->bla_a(); } } class ChildController2 extends ParentController { protected function getExtra(){ return 'usethis2'; } public function failure(){ //Rather than call a method, you'd just put your logic here directly $this->bla_b(); } }