kicken

You can try using putenv to set OPENSSL_CONF. If that doesn't work and you're need this for a site, you could set the variable in your web server's config (ie, SetEnv for apache). For a CLI script you could create an alias/script and use that to set it. You could check with your script if it's been set and if not abort with an error.

What is the error, specifically?

You need to get into the habit of calling exit; after you do a redirect with header(). Calling header does not stop the script, it will continue to run, potentially doing things you don't want it to. For example, if you had: //Redirect if not logged in. if (!isset($_SESSION['id'])){ header('Location: login.php'); } //... //Delete the selected user. $sql = 'DELETE FROM users WHERE Id=?'; $stmt=$pdo->prepare($sql); $stmt->execute([$_POST['id']]); The script will still delete the record, even if the nobody is logged in, because you didn't exit;.

So long as you're generating a valid CSS file as the output of your script, it wouldn't be any different than a normal css file from the browser's perspective. Load your CSS file directly and make sure it's outputting valid CSS and not any PHP errors/warnings etc. You'll also need to look out for potential cache issues, the browser may cache the css output which would make it not change. As an alternative to a dynamic CSS file, you could have a static css file that uses CSS variables, then override those variables with the values from the DB in your page headers (or a smaller dynamic file). This would allow the bulk of your CSS rules to remain cached and only the variables need to be reloaded. Example: style.css: /* Default values */ :root { --bg-color: #aaf; --fg-color: #000; } body { color: var(--fg-color); background-color: var(--bg-color); } page.php: <?php //Load $BG/$FG from DB, then: ?> <link rel="stylesheet" href="style.css"> <style> :root { --bg-color: <?=$BG?>; --fg-color: <?=$FG?>; } </style>

Because the javascript Date object parses the date you pick as YYYY-MM-DD 00:00:00 UTC. If you use any of the non-utc methods of that date object to access the details of that selected time, it gives you those details in your local timezone (EST) which is -5 hours from UTC (thus, the previous day). I was thinking you wanted the full date (m/d/Y) value not the day of the week, but either way the solutions are essentially the same. //1. Extract the day from the generated UTC String console.log(input.valueAsDate.toUTCString().substring(0,3)); //2. Map the day to a string via numeric index (0=Sunday) console.log(['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'][input.valueAsDate.getUTCDay()]); //3. Create a new date object adjusted for the timezone offset, then do the above but with the local functions const adjustment = ((new Date()).getTimezoneOffset()*60*1000); const cs = new Date(input.valueAsDate.getTime() + adjustment); console.log(cs.toString().substring(0,3)); console.log(['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturday'][cs.getDay()]);

Except, it absolutely does. You're getting the "wrong date" because of timezone issues, not because the change event is late or somehow using the previous value. You've been given a few ways to get the selected date as you're expecting. Use the UTC date/month/year functions and build the date yourself. Adjust the date object by the timezone offset. Extract the date from the UTC string. Pick one and roll with it.

For reference, the DOMDocument way of grabbing the content would be: $dom=new DOMDocument(); $dom->loadXML($xml); echo $dom->getElementsByTagNameNS('http://schemas.xmlsoap.org/ws/2002/12/secext', 'BinarySecurityToken')->item(0)->textContent, PHP_EOL;

This is why you need to be doing your work in a local development environment and keep your source under a version control system such as git. By doing that, you don't need to fear breaking anything. If you ever feel things are not working out, you can just roll-back your changes and start over. Only when you have everything working properly do you then publish the changes.

Javascript (like php) doesn't do date-only values, there is always an associated time and timezone. The date object you get from the input is created with the specified date at midnight UTC. You can use the UTC related functions to get back that date, but if you use the non-utc functions then the information you get back is translated to whatever the local timezone is first. Since EST is behind UTC, that means rolling back to a late hour on the previous day. If you want a date object with the selected date in the local timezone, you'll need to generate it yourself. One way is to create a new date object with a timestamp that has been adjusted by the timezone offset. https://jsfiddle.net/0dvn71e3/ //Calculate offset to local timezone const adjustment = ((new Date()).getTimezoneOffset()*60*1000); //Create a new date object with the offset applied. const cs = new Date(df.getTime() + adjustment);

The current time of day is not relevant. The date object you get from the input is set to midnight. EST is UTC - 5 hours. (2023-02-25 00:00:00) - (5 hours) = (2023-02-24 19:00:00).

That was only part of what I said. I also said: Your issue isn't with getting the wrong value back. Your issue is time zones. When you select 2/25, date you get represents 2023-02-25 00:00:00 UTC but when you're displaying that, you are displaying it in whatever your local timezone is, which for me, is Eastern Standard Time. When converting that time from UTC to Eastern standard time you get a value of 2023-02-04 19:00:00 EST. If you check the fiddle I link, it shows you both the UTC value and your local value when you choose a date.

Date inputs have a valueAsDate property you can use to get a pre-made Date object. The date object you get will be set to the midnight of the selected date UTC. When you convert that to string, it will be in whatever the browser's local timezone is, which is probably why you're seeing the day before. https://jsfiddle.net/vzhqxdsp/

Yes. When you find spam just move the message to the junk folder and let the cron job handle it from there.

If you want to use sa-learn to scan your spam / junk folders in your mail directory, then your PHP code should not be doing anything related to spam control outside of possibly moving the message to the spam folder. There's no need to deal with that spam assassin library and report/revoke the messages, sa-learn will process them whenever it is next run. Otherwise, continue to use your spam assassin library's report/revoke functions as you process messages and forget about sa-learn.

Because if I am understanding that class correctly, it already runs the message through the appropriate training when you call either the report, revoke, or learn methods. Since the message gets run through the training at that point, there's no need to do it again using sa-learn later. sa-learn is for a more passive setup where you just put messages into folders and have sa-learn periodically train on those folders. It sounds like you're doing active training on individual messages instead when means there is no need for the passive training. Of course, we don't know all the details of what you're trying to do/build but based on what's been provided so far it sounds like you're trying to make it way more complicated than it needs to be. For example, it kind of sounds like you're: Scanning a mailbox for messages Storing those messages in a DB and deleting them from the mailbox Pull those message back out of the DB Use sa-learn on them to train the filter. If you're PHP code that scans the mailbox is calling that report method, then you don't need steps 3 or 4 at all. If you're not using PHP to report the message and want to use sa-learn then it'd be simpler to just do that before you delete the messages from the mailbox, ie: Use sa-learn to train the filter Scan the mailbox for messages Store messages in DB and delete them from the mailbox.

I think maybe you're doing something that is unnecessary. Assuming you're using this class, then it seems like using the report function will automatically train the message so there's no reason to run sa-learn on it again. If you did want to use sa-learn, then you cannot just pass the path to your PHP script to it, sa-learn does not understand PHP. You would need to run your script first to generate a file sa-learn does understand, then run sa-learn with the path to that file.

You want Variable length arguments which are accomplished using the ... operator. // Using ... collects arguments and puts them into an array public function prepareSelect($query, $ts, ...$params){ // Using ... here breaks $params into individual arguments. $this->bind_param($ts, ...$params); }

Just sum the results as you read them and generate your table. $total = 0; while($fetch=mysqli_fetch_array($query)){ $total += $fetch['total']; //... } //Display your final row with $total as the sum.

If you have multiple audio tags or you're re-using the same tag for different tracks then you'll need to extend the code from using a simple true/false variable to something that can differentiate between the tags/tracks (ie, by the ID for example). An example would be to change requestSent into an array and store the ID of the played tracks into that array. To test if the track has been played, search that array for the ID.

Keep track of whether or not you've sent the count request, and only send it if you haven't. $('audio').on("play", function(){ let requestSent = false return function(){ if (requestSent){ return; } requestSent = true; let a_id = $(this).attr("id"); $.ajax({ url: "count-play.php?id=" + a_id , success: function(result){ $("."+ a_id + "count").html(result); } }); }; }()); The first time the event fires, requestSent will be false so the ajax call will run and record the play event and requestSent will be set to true. Later events will see that requestSent is true and immediately return thus doing nothing.

Sounds like a permission problem with the directory where mysql stores it's database files. Seems like your mysql setup must have not be done properly (no unix socket, bad data dir permissions, who knows what else).

That error is not Fatal error: Uncaught Error: Class "mysqli" not found, it's Your mysqli extension exists and is working just fine, the error is because your connection is failing with a no such file or directory system error. My guess is this is due to mysql trying to use a unix socket to connect, but that socket does not exist. Mysql will try and use a unix socket instead of TCP when you specify 'localhost' as the hostname. Try changing the hostname in your connect call to 127.0.0.1 instead.

The CLI version of PHP can have a different configuration than the version you'd get with whatever http server you're using. You can check the modules loaded in the CLI version by running php -m or get full phpinfo like output using php -i. Use either of those to test if mysqli is enabled. php -m | grep mysqli If it's not enabled, you can find relevant configuration files with php -i | grep .ini Look at the INI files to determine how to enable mysqli for CLI.

This is a docker-specific problem and their documentation does not appear to cover docker usage. The error tells you essentially what to do, and this is also documented in the Installing from an Archive File section.

yiisoft/yii2-app-basic seems to be setup for 7.4. Giving things a test I think this is what happened. Part of the create-project process is to run composer install to install the dependencies. This would be done on your host which probably has PHP 8.1 installed. Since the install was done using PHP 8.1, some of the dependencies has versions requiring PHP 8.1 installed. When you try and load the web page, it's using the PHP version in the docker container, which is 7.4. Since some of the installed dependencies require higher, it fails. You need to remove your existing vendor folder and composer.lock file and re-install the dependencies using the composer tool in the docker container. rm -r vendor/ composer.lock docker exec basic_php_1 composer install