sKunKbad

You could do a preg replace for chars using the following regex: $regex = '/[^\x20-\x7E\s]/'; You should also do something client-side so that the chars cannot be typed or pasted into the input fields.

I've read through most of the comments here, and wonder what you think about storing dates as epoch int(10). It seems so much easier to work with than MySql's DATE or DATETIME. I realize there is a difference in the MySQL datatypes, but it seems like more work to use them. In the light of what .josh had to say about you practically inventing the database, I thought I'd ask for your opinion (uh, fact).

Because of the way laravel handles routing this may not be possible. I say this because laravel wants you to specify specific routes. Your best hope is to use the laravel forum because there would be more exposure to laravel devs. I have to ask, why the f@$# would you do this? I see people trying to do this every so often, and dont understand why.

see http://stackoverflow.com/questions/17354217/natural-sorting-sql-order-by the sql fiddle seems to work

The problem with what you've done is that it makes the code much harder to read. When you come back to this in the future, or if somebody else has to work with your code, your nested ternary operations require much more effort to review. If instead you did something like this, anyone can understand what is going on in about 1 second: $f = isset( $Files ) ? $Files : NULL; $d = isset( $Directories ) ? $Directories : NULL; if( is_null($f) && is_null($d) ){ $error = "Neither Directories or Folders are set"; }else{ __DisplayResults__( $f, $d ); }

You could really benefit from using a well developed email sending class. Swift Mailer, at swiftmailer.org is a really nice one. It will take all of the work out of your task, and it does a lot of things you probably don't even know you need to do to send email correctly.

AKA "foreign key" I believe. As kicken suggested, you need to store all of the references to images in a separate table, then query the table for records that match the user.

Not using a responsive web design is a mistake. Don't you want to have a nice website for small screen devices?

Where are your mod_rewrite rules? It's kind of hard to figure out what you're doing without more info.

I've been successful blocking most spam with a CSRF type form token. Making javascript mandatory also gets rid of a lot of bot related spam, but the token is the real gem when it comes to blocking bots. You just set a random value in the form and in a cookie that only lasts for one request (the POST). If the value in the form doesn't match the value in the cookie, then you know the form didn't POST from a real browser.

Since you want to use Paypal, you should look at their IPN API. IPN stands for Instant Payment Notification. The notification can be sent to your website, where you intercept it and use the data in it to update your database. The data in the IPN should contain the email address of the site visitor, so you would use that as their user name to login, and you would send them an email with the password. Since I trust that site security is not extra critical, giving the site visitor the password through email is probably acceptable. Now that the user can log in, they would have access to the logged in area, until their access expires, which is something you would put in the database when you first get the IPN. So, you're going to get a little experience with the IPN API, whatever database you choose to use, and whatever Auth library you choose to use. If you use a PHP framework that already has an authentication library, then the rest is probably pretty easy.

I think it's important to consider what the modern PHP framework community is doing when it comes to routing and showing the right controller/method or anonymous function. Normally the front controller calls a bootstrap, which is a file or class that does the minimum to set up the application, route the request, and return output that is specific to the request. The request might even return a 404 page not found error. This would be a good read for you: http://phpmaster.com/autoloading-and-the-psr-0-standard/ Consider this is my front controller: <?php // No cache headers header('Expires: Wed, 13 Dec 1972 18:37:00 GMT'); header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0'); header('Pragma: no-cache'); require_once 'vendor/autoload.php'; // PATH TO FRONT CONTROLLER (this file) define( 'FCPATH', __DIR__ . '/' ); // PATH TO HEART PACKAGE define( 'HPPATH', __DIR__ . '/vendor/heart/' ); // PATH TO APP define( 'APPPATH', __DIR__ . '/app/' ); require_once 'vendor/heart/config/core.php'; // Start an output buffer, because PHP may not be set up with one. ob_start(); $app = new \Heart\Lib\Container( $cfg ); // Show memory usage for request on local machine if( $app['config']->item('mode') == 'local' ) { \FB::log( round( memory_get_usage() / 1024 / 1024, 2 ) . 'MB memory allocated to PHP' ); } // Flush any/all output buffers while( @ob_end_flush() ); /* End of file /index.php */ So you can see that the routing is not actually done here. This front controller just loads my Container class (which is extending Pimple), and once all DI objects are set THEN routing is done. The router itself is a DI object. This is my own private framework, but if you look at the Silex framework you might see what I'm talking about, since it also uses Pimple and is slightly similar. If your routing needs are super basic, and you pretty much want to rely on your own code for everything else, you might try using Slim . For any of this your are going to need to get Composer up and running on your machine, but that's not that hard to do. The upside to using modern PHP frameworks that use Composer is that you can pull in a lot of existing packages and use them, and you don't have to spend time creating functionality that is complex and could take you many hours to achieve. I know all this might sound like a bit much, but going this route will give you the skills to do what you want to do fast, painless, and in a way that is maintainable by other devs. I'm not a big fan of Laravel, but I think it's something you should look at too, since it does use composer and has it's own built in routing, core classes, helpers, etc etc.

If you ever look at the source of an email that comes to you with an attachment, you will see that there is a standard way of including the file between some delimiters, and the file is (I believe) base64 encoded. You won't be able to use the script you have without changing it substantially, and like jazzman1 said, you should just use Swift Mailer. There is a lot to consider when sending mail, and it could take you many hours to come up with a script that is half as good as Swift Mailer.

Authentication is not for beginners. You will get hacked in 2 seconds. The code you have shown above demonstrates one of the easiest things to hack. You need to read up on sql injection and proper password hashing before writing more code. You also need to read up on input validation and all of the common attack vectors. The better alternative, unless you just want to learn more about PHP, is to use somebody else's authentication library.

I think to understand use of views, you should look at some of the basic frameworks, and how they use views: CodeIgniter: http://ellislab.com/codeigniter/user-guide/general/views.html Laravel: http://laravel.com/docs/responses#views Kohana: http://kohanaframework.org/3.0/guide/kohana/mvc/views

You'll need to store the failed login attempts in your database, then check the database to see if a site visitor has too many. 1) When the login page is presented, check the IP address to see if you should even show the form. 2) When the form is submitted, check if IP or username or email address is blocked for too many login attempts. 3) When login page is presented or form submitted, delete stale login attempts (this should actually be done first)

I work with a company that uses an XML API that has some pretty massive XML data requests/responses. I know all things SimpleXML, and many scores of hours of experience with it. I've parsed this XML in various ways, and experimented with generating the XML in various ways. It doesn't really matter when you're working with some small amount of XML data, but when you've got a few hundred nodes to parse (or generate), using SimpleXML is more time consuming than just converting the whole thing to an array (or automagically creating the XML from an array). It really just boils down to less typing. I'm not saying SimpleXML is hard, but less typing is easier, especially when dealing with big XML. So yes, in real life using an array may be easier. When your fingers hurt and have numbness from your countless hours of typing, you may agree with me.

There's only one difference between a template and a view, and that would be that a template is usually the parent of some nested views. A template is just another view though. It sounds like you need a clear understanding of MVC, and devs have opinions on how MVC is to implemented, so if I describe MVC to you then keep in mind that this is how I understand it. MVC = ---------- Request is handed to a controller. Controller decides what to do with request. Controller asks for data from Model. Model may process data, including data validation. Model may set view variables, or hand data back to controller which injects them into views. Views use data to build HTML HTML is output to the browser.

A view can be a template, but can also be a snippet of HTML where there is some or no PHP. The view is usually called with an include function, but after output buffering is started, and then output when desired by echoing the output buffer or just using ob_end_flush. What all this does is allow you to set variables that are used in the view, but at the same time keep the view (which tends to be mostly HTML) out of the controller or model. Views can be nested inside other views, and if you are doing this then the nested view is usually saved as a variable instead of being output. That variable is then inserted into the parent view, which is then output to the browser. Some templating systems make use of special delimiters that designate a variable. For instance, instead of using php in a view to insert a variable named $something, some templating systems would allow you to write {{ something }}. I like my framework to be as simple as possible, so I don't use a templating system. Hope this helps.

I've only used SimpleXML, and wonder why you are using xpath? If you just need a quick and easy way to get that value, why not consider this: <?php $xml = simplexml_load_string( $xml ); $json = json_encode( $xml ); $arr = json_decode( $json, TRUE ); This will give you a simple array to work with, instead of XML which tends to take more effort to work with.

I think a problem with the CSV would be that if the file gets big then read/write times are going to be really long. You'd never have this problem with a MySQL insert. Personally I'd just use Google analytics or statcounter. You wouldn't be able to collect IP with Google analytics, because it's against their TOS, but statcounter shows it by default (unless they've changed it recently).

I was just wondering what people think, and what are your reasons why redirecting to a login page, or showing the login page instead of authenticated content is the right way. To be clear, lets say that a site visitor requests a page that requires authentication, and that site visitor is not logged in. 1) Should they be redirected to a login page? 2) Should the login page magically appear without redirect, replacing the content that would have been showed if they were logged in? Does it really matter which way login is handled? I have not been using redirects, and not experienced any problems with showing the login page instead of the authenticated content. It's actually very convenient to do login this way (at least for me). Are there any issues to be concerned with?

Look at the docs and read the part about views. You write all of your own views, which is the HTML output to the browser. Part of those views would include links to CSS, scripts, etc. So, you're not going to find anything pre-made. The whole point in using a PHP framework is to make custom apps, not just make a cookie-cutter website like Wordpress.

How about something like this: if( isset( $_SERVER["CONTENT_LENGTH"] ) && $_SERVER['REQUEST_METHOD'] == "POST" ) { if( $_SERVER["CONTENT_LENGTH"] > ( (int) get_cfg_var('post_max_size') * 1024 * 1024 ) ) { $this->error_stack[] = 'File size too large to upload.'; } } I'm using get_cfg_var because it works on all of the servers I tested, while ini_get didn't work on Litespeed.

I'm working on a file uploading script. It checks the file size, and won't let an upload complete if over a size specified in config. This all works, but if a file is uploaded that goes over PHP's limit, then I get the familiar warning: Warning: POST Content-Length of 14622352 bytes exceeds the limit of 8388608 bytes in Unknown on line 0 I am not looking to allow this file to go through. I don't want to increase memory or the max post size. That's not the issue. The upload script already has a way for the user to see if their file had problems uploading (showing errors), but how can I catch the error shown above? I know the error won't display if the error reporting and display of errors is turned off, but I don't want to leave the user in the dark. They should get some feedback. What can I do here?