requinix

Nope. What's your real code?

Yes. Using some Mail class, not vanilla mail().

Are you sure that's the direction you want to rewrite? People go to /blog.html and you want that to actually execute /blog/2013.html?

No. Because that would also remove the code dealing with the normal To: recipients. See the $to? Make sure $recipients does not have any information about the CC people or the BCC people.

Are you saying that it does not work right now? Because that query says absolutely nothing about which day's records to update.

UPDATE table SET last_dty_timestamp = /* today's date */, duty_flag = duty_flag + 1 ORDER BY last_dty_timestamp ASC /* earliest records first */, person_id /* unique ID to guarantee a stable sort */ LIMIT 4 /* only update the first four records */

Tentatively, yes. And the CC ones too. Those should both be handled with the $headers earlier.

JSON is probably your best bet. Upload: Do a POST with a request body containing the JSON data. PHP reads the body, decodes, and inserts into the database. Download: PHP reads the data from the database, JSON-encodes it, and outputs it.

if(empty($recipients)){ $recipients = $to; if(!empty($cc)){ $recipients.= "," .$cc; } if(!empty($bcc)){ $recipients.= "," .$bcc; } }Don't put the BCC list in the list of recipients. In fact, shouldn't the Mail code handle all that itself?

Actual executables? Or simply things you can run as ./script.php? For actual executables... don't. It's not worth it. PHP code was not meant to be compiled into executables. There are projects out there which say they can, but seriously reconsider whether you actually need to do that. Consider what would happen with extensions and INI settings and all that: either you would have to have PHP installed on the system anyways, or all that would need to be baked into the program, or the executable would have to be bundled with all that stuff. If ./script.php is sufficient, stick a #!/usr/bin/php(substitute the appropriate path to PHP) at the top of the file, then chmod +x it.

Regular users cannot see your PHP code. Regular users cannot "break into" code. Alright, so you want to protect the password in a general sense. Put it in a PHP file that is not part of your source code (like you don't put it up on GitHub or whatever), put it on your live server in a place that isn't part of the website (like /home/you/config when your website is at /home/you/public_html), and have your code read that file (via include/require or parse_ini_file() or whatever). If you use shared hosting then you should check the file permissions, but that depends on how the server is set up...

The password hashing/verifying stuff won't help: you cannot recover the original password once you've hashed the data. First step: what are you trying to protect against? Someone casually looking at code and seeing the password? A rogue developer who can run code in a development environment but not see any production data? Someone with shell access to the server recovering the password?

Here's a quick demonstration of what happens when you use strtotime with a phrase like "next Monday": https://3v4l.org/t9ZaI. Between Tuesday and Sunday, "next Monday" is the next Monday. On Monday itself the date will be the next week - which may be a good thing for you.

Consider hiring a lawyer/tax company for a bit to make sure you're doing things right. Getting started, the rules are complicated because you may or may not need to start making payments in the middle of the year. It has to do with how much you expect to make during the year and how it compares to what you made in the previous year. Being January you probably do, but between moving to the US and getting married and such, I don't know. (Probably.) In general, you make quarterly-ish payments according to how much money you expect to make during the year. They don't all have to be the same amount, so if you get a big job or have a dry spell then you can pay more or less for an individual payment. When tax season comes the next year you pay taxes like normal, with your quarterly payments counting as taxes paid during the year. You then get a refund (paid too much) or have to pay more (quarterly payments weren't enough) accordingly. Your clients will need to provide you with a 1099-MISC form if they pay you more than $600. They could do that when the job is done or at the end of the year. That's the self-employed equivalent to a W-2. That is then part of the tax forms you submit. The client will also submit forms like that to the IRS. If you plan to do this as a real job, like as a contractor and not mere freelancer, then you should look into forming a S-corporation because the rules are a little different and you can probably pay less taxes that way. IIRC, the most relevant forms are the 1099-MISC (payments made to you), 1040 (main tax form), and Schedule C (specific form for self-employment). I think there's another big one I'm forgetting, and there are a handful of others you'll come across.

Try port 587.

Okay, just did a test. 0. Made a repo on GitHub First directory: 1. Cloned repo, on "master" 2. Added and committed file #1 3. Branched to "branch" 4. Added and committed file #2 5. Pushed both branches, still on "branch" master and origin/master have file #1, branch and origin/branch have files #1 #2. Second directory, 6. Cloned repo, on "master" 7. Added and committed file #3 8. Pushed master Second directory's master and origin/master have files #1 #3, branch and origin/branch have files #1 #2. First directory, 9. Fetched (updated origin/master, local master still has #1) 10. Merged origin/master into master (got file #3) The branch is still where it was: files #1 and #2.

Can you post a commit graph? Looks like one of the things shown here. Here's one from GitHub: [edit] The black line is master. Didn't need to redact that.

Did you make any commits to develop once you forked from master?

No no, you can have multiple branches. You're supposed to. Mind you, if it's just you working then there's a good chance you'll just work on one branch until you're done, merge, and then start a new branch. Or maybe you have one, decide you want to do something else for a while, and start another one. But multiple branches is definitely a thing. I meant you can only have one checked out at a time. In the working directory. If you want to work on a second branch then you either (a) commit/stash your current stuff and switch branches or (b) clone a whole new second repository and do the second branch on that. The former is the normal way of doing it, and while the latter isn't necessarily wrong it can make things confusing (like "which clone was I doing $branch with?"). ...No? I don't know what you're seeing but when you do a merge/pull you're only updating the branch you have checked out. Fetch can update all remote branches but any local branch remains where it was.

fetch() will return an array. If your placeholders use the same names as the returned columns (hint: they don't) then that would work. fetchAll() will return an array of arrays. One, you cannot do a while loop on it because you will keep executing fetchAll() every time. Two, you can't execute() with an array of arrays. Use the question mark placeholders so they don't have names, then the array from fetch(). Making damn sure that you get the right columns in the right order. Which is not something I would leave to chance. $select_results = $pdo->prepare("SELECT * FROM cyptokeys"); $select_results->execute(); $header = $select_results->fetch(PDO::FETCH_ASSOC); if (!$header) { // no results? abort } try { $insert_stmt = $pdoyd->prepare( "INSERT INTO cyptokeys (`" . implode("`, `", array_keys($header)) . "`) VALUES (" . implode(", ", array_fill(0, count($header), "?")) . ")" ); } catch (PDOException $e) { // do something and abort } $row = array_values($header); do { $insert_stmt->execute($row); } while ($row = $select_results->fetch(PDO::FETCH_NUM));

Normally you work on one branch at a time. If you want your master to be up-to-date then you would do a fetch/merge (or a pull which is the same thing). Actually, for something like master, you should never be committing to it anything besides merges from other branches so I do a fast-forward merge. Normally you would then, later, decide you want to work on the develop branch. You check it out, do a merge, resolve conflicts, and begin working. No, you cannot merge into multiple branches at once with a single command. The main reason would be the difficulty with conflict resolution. What you can do is script it yourself: fetch, for each branch { checkout, merge, do something in case of conflicts (eg, pause and wait for the user to resolve), and commit }

Don't use .onclick to set a function. Are you using a Javascript library? If so, what? If not, any reason why not?

Stick the "http://" in there too.

What's the structure of the data being returned, and what is your code to load it into objects?

Looks like you have arrays within arrays. Do two foreachs. And figure out why you thought there was only one array of stuff because that suggests you aren't completely aware of what is going on.