requinix

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']);

Just because $name came from $names which is an array made up from those three variables, does not mean that you can modify $name and have that "work its way" back to the original variables. If you want to clean the $firstname, $lastname, and $username variables then you should clean the $firstname, $lastname, and $username variables.

Are you sure you put Ultimate.php in the right place? What's the code in that file?

...and the same applies to other functions, like strip_tags and str_replace and strtolower and ucfirst. They return new values and do not modify the variables you gave them.

I've tried dumbing it down. It hasn't worked so far. I don't care that it's "the same" (nor even know what it's "the same" as). I want to know how many bytes are in your key. Or bits. Same thing. Because if the number is anything other than the number I expect, that will influence how the encryption and decryption process works. So I'll ask again: how many bytes/bits are in your key? Then you have a problem because the code they gave you doesn't include a key. It also includes an IV, which is not used for (what I believe to be) .NET's default behavior of CBC mode, so either the IV is irrelevant or .NET is switching to EBC mode based on the presence of an IV. But that doesn't really matter much because it's only two possibilities to try out: with the right key, one of those two modes in PHP should produce the same output. Give me some real answers and we can make progress. I'll ask an earlier question again to echo what kicken said: create for yourself a new key that you can test with, then post it here so that we can all be on the same page.

And one more question: exactly how many bytes is your real key? There is only one correct answer to that question and I want to make sure I'm hearing it from you.

Okay, see, I'm going to have a really hard time explaining why your outputs are incorrect if I don't know what the inputs are. I get that you can't share your key, that's fine, but I need a key in order to verify whether something works. I'll try from a different angle. That C# code you posted. Is that exactly the code that was used to produce that WfRb encrypted output? If it is not the exact code, what is different?

So test your code with a different key. Go out into the internet and find samples encryptions to verify that your PHP code is producing the correct outputs. This isn't just about the C# anymore. You've got AES-256 in one place, DES is another, improper PKCS padding in your PHP where the .NET code doesn't do any... What information posted so far are you absolutely sure is correct?

With that same code I get "bimbcVvpJ/NBxllxxCsW+w==" for the encrypted output, and online sources do too. So I don't know where you're getting that Pt0MK string from, nor why you expect it to be WfRb. Also note that your key is the wrong length: a 256-bit cipher needs a 256-bit key, and if you don't provide one long enough then it gets padded with \0s.

Well, your key and IV are different, that could totally explain why you get different results. What key, IV, and input string are you testing with? What outputs do you get for the C# and PHP code samples?

(background information: by default, Composer assumes you want all the things you install to have a "minimum stability" of "stable", meaning the packages themselves are marked as being stable releases - as opposed to alpha releases, or beta releases, or "dev" releases) To see what's going on, follow these steps: 1. Take a look at your composer.lock file to see exactly which version of programarivm/php-chess was installed. You should see it as version 1.1.3. 2. Look at the repo's latest releases. You'll see that the latest version is 1.1.51. 3. For bonus points, try browsing the repo at version 1.1.3. Look at the instructions and compare with what you have done. Close but not quite the same, eh? 4. Rather than give up and go with an old version from last August, try telling composer to install version 1.1.51 instead: $ composer require "programarivm/php-chess 1.1.51" 5. Composer will complain about depending on rubix/ml being "dev-master" and how that conflicts with your "minimum-stability". The conclusion here is that since your minimum-stability is (the default of) "stable", and recent php-chess versions require a thing that is not stable, Composer won't install those. But you do want those. 6. Tell Composer that "dev" stability is fine. That might feel wrong but unfortunately this is actually a very normal thing to do because lots of developers out there don't do Good Things with their versions. $ composer config minimum-stability dev 7. Now have Composer update php-chess to the latest version. $ composer update programarivm/php-chess 8. Watch the update output to see what version it installs.

No, no, the point of what I said not about me doing the work. The part of that post you skipped over was "for the same reason", meaning I was trying to demonstrate the "that will not work" point using an example. I'll try some different examples, okay? Having PHP access the user's current version of the webpage at all - forget DOMDocument, that has nothing to do with any of this - will not work for the same reason as why you cannot 1. Fill your car's gas tank while you sit at home (because the gas is at the gas station and you are not) 2. Pull a turkey out of the oven while you are filling up your car's gas tank (because the the oven at home and you are not) 3. Climb Mt. Everest with a hot turkey you just pulled out of your oven (because Mt. Everest is in a remote location in Asia and your oven is not) Do you see the pattern here? The HTML table you want to access is located inside your user's browser while the PHP code is running on the server. To exchange data you have to exchange the data, meaning the client's browser (where the data currently is) has to be sent the information about the table/hex colors to the PHP server (where you want the data to be). Sending information from the browser to the server is done by either (a) using HTML forms, which you said you don't want to do, therefore forcing you into the only other option of (b) using Javascript and AJAX.