maxxd

You get the data to the server by submitting the form. You can do it traditionally or via AJAX, but either way the data has to be submitted to get to the PHP. I don't know cake, but if you normally get the request data via $this->request->getData() but it's empty in this case then something's wrong elsewhere.

There's probably a Cake-specific method of creating form fields with an array-enabled name, but I don't have the slightest notion what it would be. To answer your other question, you'll need to submit the form data. Whether you do it via AJAX or a traditional HTML submit doesn't matter - send the data to the PHP script and process it there. I'm not going to lie, given what you've described I'm hard-pressed to believe that what you're doing is actually what you want to do, but then again I don't know your project.

You haven't set a value for the drag12 element, so there's nothing for the JS to get.

The data you're sending from AJAX doesn't include a 'submit' index, which loginizer.php requires to do anything.

You can set the domain (and path, even) for cookies.

So CPANEL is a dependency package that you've not included in your script. I don't use cPanel so I'm not sure how it's set up, but there should be a require or include directive in the script somewhere - either it'll include the script directly, or it'll include an autoloader file in which case you'll see a use statement naming the CPANEL class.

Sorry, but this is completely incorrect. Single quotes in PHP will not interpolate variables, while double quotes will. So this: echo '$var'; will output $var , and echo "$var"; will output value

I didn't read all your code, but on a macro-level you have a couple choices. Either get all the information on page load and use PHP to put it into JS variables or HTML data attributes, or use AJAX on the mouse over event and do it dynamically (slower, but IMO a better choice).

It looks like you're trying to combine cURL CLI and cURL php. They aren't interchangeable or compatible. Follow the link gw1500se gave you, then consider NotionCommon's advice.

What you've done is create an array of strings. The Book objects that represent 'Moby Dick' and 'Wuthering Heights' are $first_book and $second_book. So this is what you're looking for: $book = array($first_book, $second_book);

In your select query, limit the result by the user ID. I assume you're tracking user ID along with list item, yeah?

Perhaps consider changing to mysqli? Though, truth be told, PDO is easier...

It means that either the body property of your response object doesn't exist or isn't an object. Try putting this at line 11: die('<pre>'.var_export($response, true).'</pre>');

If you're pulling data from WordPress but not using it as the CMS (so basically, it's headless) then your page doesn't know what to do with the WordPress functions you're calling. That's what I mean by mixing CMSs, you're relying on the PHPjabbers stuff to handle the bracketed text replacement and WordPress to hand the_posts(), the_title(), the_excerpt(), etc. Pick one - make sure you include the proper WordPress handler code, or use WordPress and include the PHPjabber script in the WordPress template file and use it there.

It looks like you're mixing CMSs? WordPress by itself doesn't understand mustache notation, so {SCMS_CONTENT_2} means nothing to it unless you're using a theme or plugin that parses that code. the_title() will echo by default - you can turn echo off by passing false to the third parameter.

It's very easy to do that with WordPress if you're not careful. Hit the codex. The documentation for WordPress is actually quite good.

create_callback is the function that's been deprecated - neither preg_replace nor preg_replace_callback have. The second bit of code looks OK from a cursory glance. What's the actual error message you're seeing from it?

What error have you gotten from both lines?

Personally I like to refine and/or finesse the data as necessary in the controller before it reaches the view. This sets up basically very dumb views where any business logic is taken care of before the view is rendered. However, part of the system I'm currently working on does pretty much what you describe and passes raw data directly to the view where it decides what to display and how and it works just fine. As requinix points out, some degree of coupling is pretty much unavoidable so I guess it depends on what's easiest for you reason about.

You're going to have to deal with JavaScript for the fingerprint scanning - try Googling "javascript biometric authentication" .

The first code block doesn't work because of variable scope in PHP. The $fcont inside the class is not the same $fcont as the one outside the class. There are several ways to fix the issue, and given where you appear to be in learning PHP your solution in the second code block is fine albeit not ideal. Another solution is to build the string in the class method and return it to the calling code, which then prints the result. The best and most advanced option is to use a templating language like Twig or Blade, though that's probably going to be a topic for the future.

You shouldn't have multiple elements with the same ID. In your case, your input is being duplicated and the id is "chat_message_{to_user_id}", so when there are multiple instances of the input element they're all assigned the same id - in this case, "chant_message_13".

Add error reporting to the top of your script: error_reporting(-1); ini_set('display_errors', true);

I pretty much agree with kicken, but feel the need to throw in my own two cents. First off, tip #3 is something everyone who codes should live by. To add to it, don't string together a million conditionals - I'm currently dealing with a code base that has a 180-line if-elseif-else tree and it makes me wanna barf. For what is supposed to be a conditional logic operation, this is shockingly devoid of both condition and logic. Personally, I think any sort of hard and fast numerical limit on function/method/class width or length is kinda manufactured. Use judgment and good formatting. For the width, break across lines when it becomes hard to read. For instance, there's nothing inherently wrong with this code: if(empty($_POST['firstname']) || empty($_POST['lastname'])){ // ... } Plenty easy to read, but if you've got more validation to do, this becomes a nightmare and should be broken, like so: if( empty($_POST['firstname']) || empty($_POST['lastname']) || empty($_POST['middlename']) || empty($_POST['fieldicareabout']) || empty($_POST['anotherimportantfield']) || empty($_POST['myrefridgerator']) ){ // ... } Granted, this board's indenting is far larger than mine in VSCode, but hopefully you get the point. As far as length, methods should do one thing, and objects should handle one situation. What you've got now is what's called a god object in OOP, and it's - as you're finding - difficult to reason about and maintain. On the other hand, the issue you can run into with one function per file is that it can become a mess of code relationship that's hard to follow if you're not extremely diligent. It also absolutely requires a full test suite because chances are you'll be including the same file in multiple places, and this can lead to hard to find bugs when you forget you use a function somewhere in a different part of the code. And finally, just to beat the horse some more, format everything appropriately. I've spent untold hours at work trying to parse SQL queries because the original author wrote them out in one long line instead of using line breaks and indenting to make it make sense. Obviously PHP isn't Python or Ruby in that indentation doesn't actually affect the code, but there's a reason the authors of some programming languages chose to use indentation instead of brackets or curly braces - it makes the code easier to read, and illuminates the intention of the functionality. Wait - I lied; one more thing (it's late but I'm not sleepy and my mind is going, sorry). Absolutely use descriptive and appropriate method and variable names, but document as well. Just because your method is called `applySalesTax` doesn't mean I feel like parsing the entire method to figure out how or why you're applying sales tax. For instance you can assume that people know that sales tax is different across states, but if you don't charge sales tax in North Carolina as a business decision or due to a legal loophole, put that in the docblock.

Make an array of the required form fields in php, then loop through that array on submission. If any of the fields are empty, add a message to an errors array. In the end of the actual, full form processing script if the errors array isn't empty, loop through the errors array and print out each individual error.