requinix

You haven't installed Node globally.

This is a "try it and find out" situation. If you've tried it and discovered that the use statements in the trait's file can be picked up by the annotation parser then there's your answer.

while($rows=mysqli_fetch_array($result));

It would be easier to know what the right direction is if we had a more detailed description, or perhaps even examples, of what you wanted to do. If you want to send the email always and only include in it particular values then your code there isn't right because it constructs the entire email based on that field. You would need the contents of the email and then to insert some piece(s) depending on $item5. Yeah, I think some examples would be nice.

The best way to test it would be to put it on the internet and see what happens. What's wrong with reCAPTCHA? It's very good at what it does.

It's not cumulative. The group talks amongst itself to arrive at one point value, with one or more members possibly increasing their ratings based on discussion, or (less commonly) others lowering theirs. https://www.google.com/search?q=scrum+point+system

To be clear, procedural versus object-oriented code has absolutely nothing to do with server security. Either people can see your code and files or they cannot.

Then how about changing your approach to allowing multiple uploads of the same file that will create duplicates, but giving people an easy way to (1) store documents under their account or something similar, then (2) "sharing" those documents with whatever projects. Vendors upload documents, like certificates and proofs and whatever, and then add those documents to their project. It creates a clearer understanding that there's effectively only the one document which is being shared with the end users. And, frankly, I think it models the real-world behavior better than worrying about detecting identical files.

Do the users know that these files are unique? Because I would expect that most of the file, when someone uploads a file to a place then they'll expect it to be available at that place. Personally, I think it would be weird to search for a file that I know was uploaded 10 different times and only see one search result.

Why do you care about having them both share the same bytes? Disk space is cheap, and this scheme is making stuff complicated.

So there's a very specific company-name you want to do this redirect for? Why does it have to be a variable?

Oh, dammit, I'm thinking about this all backwards. The odds of a collision are mostly irrelevant because they're unlikely to happen unless the files are identical. And that is going to happen. But MD5 is still fine because it's still astronomical for the hashes of two different files to match. All it does is increase the average number of files you'll have to manually compare by a negligible amount.

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.