requinix

It seems like you simply have the wrong username and/or password. Is there a place where you configure user accounts? Does it say that actual username? Sure you have the right password? You are connecting to the database from code running on hosted site, right? Not locally?

I wasn't trying to I wouldn't use my own code for real because it's not clear how it works. There's something to be said for code that's longer but easier to understand.

And the code for Session_DB_Handler would be...

Have you considered showing us the code so we don't have to make blind guesses?

No string manipulation functions? No functions at all! Unfortunately it turned out much simpler than I thought it would. $input = " this is phpfreaks"; $output = ""; $word = ""; for ($i = 0; @$input[$i] != ""; $i++) { if ($input[$i] == " ") { $output = " " . $word . $output; $word = ""; } else { $word = $word . $input[$i]; } } $output = $word . $output; echo "[{$output}]\n"; [phpfreaks is this ]

You've got a try/catch up there at the top that will show an error message if PDO had a problem. Was there an error?

The problem is (due to emulated prepares, but is) moot: you cannot use prepared statements there. They are only for passing actual data into a query - you can't use them for things like CREATE TABLEs.

Not sure what a hostname has to do with any of that code... How about posting the rest of it? Be sure to include the bit where $dbh gets defined.

It's logging the value of colorHolder, which is a class name from some element. The code is pretty clear about that. Are you sure there isn't something else modifying that variable?

Adding up? Multiplying?

Doesn't make a difference.

So you're saying that you don't have any other sort of redirection code in place anywhere, but if you go to absolutely any "file" that has two underscores in it and no trailing slash, and does not exist in any form there whatsoever, you are being redirected to the same location but with the trailing slash? So if you go to /abc_def_ghi then you get redirected to /abc/def/ghi/?

Well, it's like your .htaccess says: RewriteCond %{REQUEST_FILENAME} !-d"don't rewrite if the target is an existing directory". Which is a good idea to do: you probably shouldn't have a file and a directory with the same name.

Use a foreach loop on $site. Each value will be an array that looks like the $anyvariable you want.

One of them. You escape one of them. The one that you are using for the string delimiters. Not both of them.

The backslash problem is because you're putting backslashes in places that don't need it. Since the backslashes aren't necessarily there, PHP keeps them in place thinking that you wanted literal backslashes. Don't use them for single quotes in a double-quoted string, or vice versa. Whatever you're experiencing is not due to PHP. I'm more troubled by the "3000 random characters and it worked" statement, which must mean something besides other than what those words literally mean. This is probably the time when you should be looking more closely at the API itself. If the code returns null then look to see under what conditions it will return null. Trace it back up to the actual API call (or whatever) and find out exactly what's happening. Because poking and prodding with different strings here and there isn't making much progress.

What quotes?

I'm a little confused now. You agree that require_once() is the best solution, but are doing something else instead? Calling header() will not stop your script. It'll keep executing. So if all you did was add that line then the error would keep happening. 1. email_users() should be only about emailing users. It shouldn't have to do anything with a redirect. 2. The redirect should be in the calling code after all, because it's the calling code that knows that it was a web request in the first place and that the user should be sent to that page when successful. 3. Changing all your include/require()s that are for files which define classes or functions to use include_once/require_once() instead will solve your problem. Though you should still look into why the file was included twice as that could (could) be a symptom of another problem.

That's pretty specific. Have you considered learning PHP and writing the code yourself?

Your first regex is way too permissive. '#(http://)(www.)(?:youtube(?:-nocookie)?\.com/(?:[^/]+/.+/|(?:v|e(?:mbed)?)/|.*[?&]v=)|youtu\.be/)([^"&?/ ]{11})#x' [^/]+/.+/Regexes are greedy: they will match as much as possible and only backtrack if they encounter a problem matching the rest of the pattern. [^/]+ will match anything up until the next slash (which is the slash in the first "") then a slash, then any amount of anything which will take it all the way to the end of the line, then backtrack until it finds another slash (which is the last slash in the MP3 URL). Then 11 characters will match "leonhardt_s" and the MP3 regex is left with just "kaar_2015.mp3". The easiest modification is to make sure the regex stops at whitespace too, not just a slash. The first portion will fail because there isn't another slash to find, the second portion won't match, and the third will. However the third is way too permissive as well because of the .*. You can change that to match anything but ?, &, and whitespace just in case. '#(http://)(www.)(?:youtube(?:-nocookie)?\.com/(?:[^/\s]+/.+/|(?:v|e(?:mbed)?)/|[^?&\s]*[?&]v=)|youtu\.be/)([^"&?/ ]{11})#x' By the way, the HTML in your $replacements[1] is wrong. And there's no point to using the /x flag if you're not using regex comments.

"Fatal error" means your script is crashing. That is not good. The fact that it crashes after sending the email is fortunate but still not acceptable. Whatever file that contains the PHPMailerAutoload function is being included twice. That's a problem because you're telling PHP that you want to define this function twice. Which is bad. Use include_once() or require_once() instead (the latter is better for a dependency) to tell PHP that those files should only be included once. Do that everywhere you include files which define classes or functions or autoloaders.

And now what happens if you put that all into a literal string and call the API with it directly? You should get the same error. The next question is what did you put in the "a string here" that made the API call work, and how does it differ with $yaml?

Sounds like you should be locating //div[@class=prog_cols] first, then within each of those locating the three parts you want.

You mean which style is better, quotation marks or named placeholders? There's no difference technically, but if you use named placeholders then it's easier to make sure your variables are lined up correctly and less risk of accidentally putting variables in the wrong place.

You are definitely passing a string, so the problem must lie within the value of $yaml itself.