requinix

There are some caching nuances to consider, some from PHP and some from the operating system, but there is one thing you forgot with the hash test: The hash for the first file is only going to be calculated once. The compare-by-hash test would be more accurate if you gave it a hash string for the first file, which should reduce the execution time by about half. function compareFilesHashTest(string $file_a, string $file_b, string $algo = 'md5') { $hash_a = hash_file($algo, $file_a); $time = microtime(true); display($time, $file_a, $file_b, 'compareFilesHashTest', $hash_a===hash_file($algo, $file_b), $algo); } >99.9% of the time, the hash will catch the duplication. For the remainder, the file size is a very easy hurdle to clear before you move on to the longer process of reading the contents from both files. As for hashing algorithm, you don't need security here. What you need is an algorithm that is fast and will produce enough entropy so that hashes are the least likely to collide. MD5 is faster than SHA-1, and while it has 128 bits compared to the other's 160 bits, odds are still that you'll need more than (a number 20-digits long) documents before you hit a collision.

As long as you're only looking for honest and accidental duplication: store a hash, look for duplicates (which will be highly unlikely), and if you find any, compare the actual files' sizes and contents.

If you change the database information so that it doesn't connect anymore, like with the wrong password, does the application stop working?

Did you modify art_order so that "folder" comes in the list before the services?

Perhaps a stupid question but if we're talking about the configuration file for some PHP application on your server, have you tried just changing the "INI" file?

What does your current code look like now that you added the private $db; to it?

Re-read what INI file? Why is it changing?

Because PHP could not open the file. If you didn't see any error about that fact then it means you do not have your PHP environment set up properly for development. Find your php.ini, go to the bottom of the file, and add error_reporting = -1 display_errors = 1 then restart your webserver and/or PHP. Then try with the code using require() as it was before and make sure you see the error message(s) from PHP. That's one way to think about it, however there are virtually no reasons why you should ever be trying to load a PHP file that isn't necessary for your code to continue running. And that's the difference between them: both will look for the file and run it if it exists, but include() will let you continue running if it did not. Which raises the question of why you were trying to include() a file that did not exist. Rule of thumb: always use require().

->with('a',$data1) The first argument to with() is the name of the variable you want to create inside the view. The second one is its value.

Sessions are easy unless you have a terribly architected website. Kinda. Nobody likes tracking cookies. People don't know it but they do like cookies. Enjoy your lawsuit. The only way a session should have noticeable overhead on your site is if your webserver is a potato. Not as many as you think. Even so, these people do like using the internet, which requires cookies to function, so they're necessarily used to adding exceptions in their browsers. For relatively small databases at relatively low activity levels, yes. It doesn't do as well at high traffic, high concurrency loads as some other systems. If you thought sessions were hard then databases are going to be harder. *Tracking cookies. If you want to disallow all cookies then there are a lot of completely normal things you're going to have to make do without. Such as: You can't. Not without cookies. Not safely. edit: Actually no, it is possible, but it creates a terrible user experience: the user can't use their back and forward history buttons.

1. Events do not cause recursion, and so shouldn't cause any stack size problems. 2. I don't see any recursion in the code. What's all the code for this form?

https://www.google.com/search?q=how+to+use+blade+templates+in+laravel

Sounds like you should code it with a view that renders the different forms, a controller that handles that one view, and when submitted the controller checks the form data to decide which other controller should be used to handle the requested action. The concept you're working towards is something like partial views, or using components instead of view pages. Not a common thing to see with a PHP MVC framework. This scheme tends to be handled in more of an event-driven way: the view and controller are more closely coupled and set up for a collection of view "components", the view tells the components to render themselves (eg, a "render" event) and the controller tells components to handle form submissions (eg, a "submit" event). Components can contain other components. This starts to get complicated because you need a way to separate the different components' form data from each other, meaning form rendering helpers that make it easier to deal with form data naming schemes; a top-level component Foo may want a "name" form field, the rendering helper actually renders it as a "Foo" prefix + "name", and later some mechanism decodes the form data and component hierarchy to make sure that Foo properly gets the "name" it expects. But that's complicated. If you're learning MVC then try to stick to the standard MVC ways of doing things. In this case, the standard solution is to have your view render all of the forms and fields itself, then the controller receives all of the data and decides what to do. Consider that it's perfectly fine to create for yourself a sort of "form for table X" class to help reduce the amount of work the controllers and views have to do on their own.

That is not quite an accurate description. PHP has exactly two variable scopes: one for inside of functions (each function gets its own and it isn't shared with other functions) and one for outside of functions (normally referred to as the global scope, which is the same everywhere and even shared across files). <?php $a = 1; // global scope echo $a; // 1 function one() { echo $a; // empty: $a from the global scope is not available inside this function scope so this "$a" is different $a = 2; // a new variable in the function scope echo $a; // 2 } one(); function two() { echo $a; // $a from the global scope or one's scope is not available inside here either $a = 3; // a new variable echo $a; // 3 } two(); one(); // will output the same thing as before: first echo shows nothing, second echo shows 2 echo $a; // still 1 Code in functions can use the "global" keyword to access the global scope, but this is very strongly discouraged. With classes, their functions ("methods") have a function scope just like every other regular function has. What PHP does differently is give you a "$this" variable corresponding to the instance of the class. $this->db is using the $this variable (scoped only to the method) to access its "db" property (which has nothing to do with scope). <?php class Example { public $a; public function one() { echo $this->a; $this->a = 1; echo $this->a; } public function two() { echo $this->a; } } $example = new Example(); $example->one(); // first echo shows nothing because $a is undefined, second shows 1 $example->two(); // also 1 // echo $this->a; // "$this" is only available inside class methods $example->a = 2; $example->two(); // 2 Variable scope only matters for variables, as in things that use dollar signs, and besides the "public $a" (whose dollar sign is really more about the syntax for defining "a" in the Example class), there are only two ways that dollar signs are used in the above code: with $this and with $example.

If you see any code that uses "global", as in global $db = new PDO($data,DB_USER,DB_PASS); then it's out of date and shouldn't be used. This code here $statement = $this->db->query($sql); is trying to use the "db" thing correctly, however the "db" isn't being defined correctly. $this->db means there is a "db" property/member variable on the class. You define it like class Connection { private $db; (it goes inside the class { } but not in any of the functions; "private" means only the Connection class can access it) and then actually give it a value with code that looks the same as how the other place was going to use it: $this->db = new PDO($data,DB_USER,DB_PASS);

So if I tried to format as "mmm", what would it do? Months? Minutes? Combination of both? Check the documentation, or look up earlier in your code to see what you should be using instead.

What does "m" mean?

Have you already checked that the server time is correct?

That's probably it, yeah. How about pasting the relevant parts of your code into a post so we don't have to download stuff? Click the <> button, paste code, insert.

What is $request[1] supposed to be? Don't you mean $id?

You accomplish this by not storing multiple values in a single column. Create another table that will remember each sessionid / flavor pair. There will be one row for session_id() and vanilla, then a second row for chocolate, then a third row for strawberry. If you make the sessionid + flavor unique then you can try to insert another chocolate row but MySQL will tell you it can't (because there already is one).

If you're looking to pay someone to do the work then go to our Job Offerings forum. If you want help to do it yourself then you're going to have to explain, in much more detail, what it is that you want to do.

app and App are two different things.

Oh. use app\Ultimate; Look closely.

Right. And the function is a good decision to reduce duplication. What I mean is, this doesn't have to be much more complicated than just $firstname = clean_names($_POST['firstname']); $lastname = clean_names($_POST['lastname']); $username = clean_names($_POST['username']);