maxxd

It's a deep dive into nerdom, but they are handy to at least recognize.

I'm not awesome with RegEx in general, but I typically use https://regexr.com/ as a playground with decent documentation.

You're limiting yourself by trying to do everything at once. Take it in logical steps: if( $d != 'Yes' && $c != 'Yes' && $o != 'Yes' ) { echo 'Nope'; return false; } if($p != 'Yes'){ echo 'Nope'; return false; } echo 'Yup'; return true; If all the three additional variables is not 'Yes', kill it. If any of the three is 'Yes', check the value of $p (you can switch these around if you want, it shouldn't matter). If $p is not 'Yes', kill it. Otherwise, you know $p is 'Yes' and at least one of the other three variables is 'Yes', so your criteria is met and you can continue with your logic.

mac_gyver is 100% correct with those suggestions. I will add that using '?' placeholders can get confusing if you've got several to many variables in your query - in this case i recommend named placeholders. So, to update mac_gyver's perfectly good code as an example, $sql = "Select * FROM weekends WHERE Weekend_Number = :weekendNumber AND Men_Women = :menWomen"; $stmt = $pdo->prepare($sql); $stmt->execute([ 'weekendNumber' => $_SESSION['Weekend_Number'], 'menWomen' => $_SESSION['Men_Women'] ]); Note that another benefit of using PDO over mysqli is that you don't have to bind the parameters separately. It's been a while since I used mysqli, but i think i remember having to bind the result values as well? If I'm remembering correctly, this is another thing you don't have to do with PDO.

There are issues here beyond the error you're seeing. First and foremost, drop mysqli_* and use PDO - it's easier to use and can handle several different SQL dialects. Secondly, never put raw user data into a query (session data can be modified by the user). Use prepared statements in order to not lose or expose your data. As to the actual issue you're seeing, print out the value of $Number and $MW before you run the query to make sure they contain what you think they contain. If the value is actually '55th' you need quotes around the value - another bonus of using prepared statements (preparing the statement will take care of that for you).

In any code that I work with that doesn't use a templating engine I try to label my conditionals, like so: <div class="slew-of-form-elements"> <?php if($myVar === true): ?> <input type="text" name="field_1"> <select name="field_2"> <option value="-1">Select an option</option> <?php foreach($options as $key=>$value): ?> <option value="<?= $key; ?>"><?= $value; ?></option> <?php endforeach; // $options as $option ?> </select> <?php endif; // $myVar === true ?> </div> Obviously this is a contrived example and is missing things like output sanitization and the many, many, many form elements some of the code deals with but hopefully the point comes across.

Class methods do not have to match the constructor's signature - each method can require as many or as few properties as it needs. For instance, given your example, this is perfectly acceptable: <?php class FeatureRequests { private $details = []; public function __construct(array $details) { $this->details = $details; } public function getAllDetails() { return $this->details; } public function getDetail($index) { if(isset($this->details[$detail])){ return $this->details[$detail]; }else{ return 'Index not set'; } } } In this case, the constructor requires an array, getDetail() requires a string, and getAllDetails() doesn't require any parameters. What matter is that when you invoke the object method, you pass it the parameters it needs.

/homepages/29/d1007800584/htdocs is your site root - this is set by your host at the server level. If site-header.php and tester-include.php are both in the /page/ directory, the include from tester-include.php should be simply `require_once('./site-header.php');` If that still doesn't work, try `require_once(dirname(__FILE__).'/site-header.php');` (if site-header.php is in a sub-directory called /root/, add that into the require). As an aside, your host should be on php 8.1 at the least - 7.4 reached end of life in November 2022. You may want to ask them why they haven't upgraded yet. If they can't give you a decent answer, there are plenty of low-cost modern hosts around - ask here. Someone can point you in the right direction.

Saw that earlier but it's possible I wasn't in the mindset to read it completely - I'll take another look. Thanks much!

I have a method that is trying to recognize legitimate names from data submitted by the user. I've got an array of obscene words, an array of bullshit words I've seen in past submissions, an array of just random strings that I've culled over time that I check against. I'm looking now at using AWS Comprehend DetectEntities as a last resort and it works - I hate to admit this - very well. The problem is that there is a phpunit group of tests that passed before the new code needed the actual AWS Comprehend call credentials to test. I'm having issues mocking the ComprehendClient object. $c = $this->getMockBuilder(ComprehendClient::class) ->setConstructorArgs([ 'args' => [], ]) ->addMethods(['detectEntities']) ->getMock(); $c->expects(self::once()) ->method('detectEntities') ->with([ 'LanguageCode' => 'en', 'Text' => 'string' ]) ->willReturn(true); $this->assertTrue(ComprehendController::validateName('Bob')); returns The service "ockobject_comprehendclient_a8" is not provided by the AWS SDK for PHP. And $cce = new class extends ComprehendClient { public function __construct(){ parent::__construct([ 'credentials' => [], 'region' => 'us-west-2', 'version' => 'latest' ]); } public function detectEntities($args = []) { return true; } }; $c = $this->getMockBuilder($cce::class) ->setConstructorArgs([ 'args' => [], ]) ->setMockClassName(ComprehendClient::class) ->addMethods(['detectEntities']) ->getMock(); $c->expects(self::once()) ->method('detectEntities') ->with([ 'LanguageCode' => 'en', 'Text' => 'string' ]) ->willReturn(true); $this->assertTrue(ComprehendController::validateName('Bob')); returns The service "comprehendclient@anonymous\/home/my-dir/project/tests/unit/testcomprehend.php" is not provided by the AWS SDK for PHP. Can anyone point me to a decent tutorial on how the hell to mock an aws object in phpunit? It's kinda driving me nuts...

First and foremost, the mysql_* functions were removed from PHP quite some time ago. Look into PDO for all your database needs. That having been said, a lot of old code still exists on the internet, so don't blindly copy and paste. The good aspect of the code you're using is that it's using PHPMailer instead of php's native mail function. Not to be rude, but the rest of it is dusty and shouldn't be used.

Yeah, honestly forget that MySQLi even exists - PDO is better and much easier.

If you have added the connection code, check your browser tools network tab to see if something is throwing an error. Just a couple weeks ago I spent several hours debugging a script that was barfing and come to find out I had typed 'context' instead of 'content' in a column name.

CodeIgniter 4 is leaps and bounds better than 3 - it was re-written from scratch to make use of modern development patterns. That being said, as gizmola mentioned it was still pretty bare-bones last time I used it, whereas Laravel is fully featured. Some may say too fully featured, but it's optimized very well and has a large and active ecosystem. For instance, if you don't want to pay for Pusher they just released Reverb, which is a Laravel-specific websocket package that isn't the easiest thing to set up, but once you do it's quite good. It has a robust queue system that allows the developer to do a lot of work asynchronously right out of the box. The learning curve is steep, but most frameworks have that problem. Just know going in that there is a lot of magic to Laravel, so making sure you're comfortable reading source code is important (although the docs are better than most, IMO). I've not used Symfony specifically but - again as gizmola says - Laravel is built heavily on Symfony components. Best bet is to try building something smallish in all three and see which sings to you. Personally, even recognizing that Laravel has plenty of warts I prefer to work in it (though that may be Stockholm Syndrome as I've been working with it almost exclusively for about 6 years now).

☝️