requinix

-- universally(ish) means to stop processing command line arguments and treat the rest as literals. If you did php -f file.php -hthen PHP would think you wanted to see its help. If you did php -f file.php -- -hthen PHP would run file.php and pass it "-h" in $argv[1]. If you used -f with the command then you would need --, but without -f PHP implicitly stops parsing arguments after the filename. php filename args... php -f filename -- args... And no, I don't know why PHP_BINARY doesn't have a value. Are you calling the first script from the command line?

You mean the one that doesn't exist anymore? The one that's been replaced with "FormValidation"? The one that doesn't seem to have any documentation preserved? Fortunately archive.org has a copy from back in September 2014. You know, when the version you're using is from. Try calling revalidateField on "street" and "place" when they get (re?)added to the form.

Which "Bootstrap Validator" are you using?

Bwahaha, I got the command wrong. args... Arguments passed to script. Use -- args when first argument starts with - or script is read from stdinSo I was a bit overzealous in using --. The command should be $command="/usr/bin/php" . escapeshellarg($script) . " " .$args;

Output PHP_BINARY . " -- " . escapeshellarg($path_to_second_script) . " " .$argsand make sure it's the correct command.

That code is basically just a fancy wrapper around proc_open. If all you need to do is simply run code/a file then it's, like, 15 lines of PHP to do so...

You want what? Explain how this expiration thing is supposed to work.

Clearly not everything is correct. Check your database information again. Make sure your database users are set up correctly. Look at whatever else is relevant.

It would be nice if you could share what you discovered, since I know that there's something else going on besides PHP "not liking" that zero...

That's an option? That class? You should do that. Yeah it's more code, but it's more flexible and lends itself really well to testing.

Looks like PhpEd has its own debugger they want you to use? If that doesn't work for you then you can look to see if there's a way to get Xdebug working with it instead. (Netbeans user here so I don't know.) As for php://input, that will be empty unless you're running the script through the console with something piped into it. (I think - that might only be for stdin.) I don't think you can give it a value short of implementing your own php:// wrapper, which would suck. I think the best option would be two scripts: one script calls the other through the shell and pipes in the $post data, then the other to fill in $_GET and $_POST and such appropriately. I've used that kind of strategy before with my own code... which is somewhere... I don't quite remember... It's used as part of a unit testing framework, albeit mostly for launching PHP processes under specific configurations. // first script function simulateRequest($method, $url, $get, $post) { $query = http_build_query($get ?: []); $input = http_build_query($post ?: []); // pass most information through argv $args = implode(" ", array( escapeshellarg($path_to_second_script), escapeshellarg($method), escapeshellarg($url), escapeshellarg($query) )); $descriptors = array( 0 => array("pipe", "r"), 1 => STDOUT, 2 => STDERR ); // launch php with the second script and write to it the post data $p = proc_open(PHP_BINARY . " -- " . escapeshellarg($path_to_second_script) . " " . , $descriptors, $pipes); fwrite($pipes[0], $input); fclose($pipes[0]); proc_close($p); } list(, $method, $url, $query) = $argv; parse_str($query ?: "", $_GET); parse_str(file_get_contents("php://input"), $_POST); $_REQUEST = // really you should evaluate this according to request_order // etc. // then continue the startup process Meanwhile $opts = ['http' =>['method' => 'POST','header' => 'Content-type: application/x-www-form-urlencoded','content' => http_build_query($post)]]; $context = stream_context_create($opts); $rawInput = fopen('php://input', 'r'); stream_copy_to_stream($context,$rawInput); is really, really wrong. OH FOR FRICK'S SAKE, why is the indentation broken? Blargh.

Right. You can't use something in the global namespace, but adding a backslash is easier anyways. Doesn't matter. Personally I wouldn't, simply because the code isn't using namespaces so I wouldn't "introduce" namespaces into it. But you can if you want. Consistency, maybe? It's an autoloader for the most common class/file hierarchy: you have a file at /path/to/classes/Foo/Bar/Baz.php containing the class Foo\Bar\Baz. Nothing special with filenames, no sanity checks, just a simple class-to-path conversion method to find the right file. But like I said, if you want to use that method then you should just use the built-in autoloading logic. Because it does the same thing.

PHP needs fully-qualified names to determine what classes are. If you write just "PDO" then PHP will think you want the PDO class in the current namespace; if you're not in a namespace then great, otherwise it won't find the class (unless you happen to have one with that name). Write \PDO. The class will be like "Path\To\Class"; the common answer is to convert backslashes to DIRECTORY_SEPARATORs and look for a matching filename. spl_autoload_register(function($classname) { $path = str_replace("\\", DIRECTORY_SEPARATOR, $classname); require "/path/to/classes/{$path}.php"; });But if that's all you need to do then you might as well use the built-in spl_autoload and put your /path/to/classes in the include path. spl_autoload_register(); // equivalent to spl_autoload_register("spl_autoload") Your autoloader ignores the entire namespace and only uses the class name. It will not be able to handle multiple classes with the same name but in different namespaces, like "Foo\Example" and "Bar\Example".

use (the one for namespaces) helps you not have to repeat fully-qualified names everywhere. That's really all it does. I won't name names, but there are folks out there who write classes like namespace Framework\Database\AbstractRecord\BaseClasses\TableBase; abstract class DefaultTableBaseImplementation {(there'd actually be an interface in there...) To use that in your code you'd normally write class MyDatabaseTable extends \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation {That's rather unwieldy but acceptable on its own. Now imagine you have to reference a number of different classes. Say, traits: class MyDatabaseTable extends \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation { use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableLowercaseNameTraitBase; use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableNoPrimaryKeyTraitBase; use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode\TableIsViewTraitBase; (which demonstrates a different use...) Writing that all out every time sucks and encourages you to copy/paste code (something I hate). With a use statement you can use \Framework\Database\AbstractRecord\BaseClasses\TableBase\DefaultTableBaseImplementation; // whole class use \Framework\Database\AbstractRecord\BaseTraitsThatEverybodyShouldUseToSaveTimeWritingCode as FBaseTraits; // can have a shorter alias class MyDatabaseTable extends DefaultTableBaseImplementation { // easier to read use FBaseTraits\TableLowercaseNameTraitBase; use FBaseTraits\TableNoPrimaryKeyTraitBase; use FBaseTraits\TableIsViewTraitBase;

Yes it is now available to everyone. But that doesn't mean the original "array()" syntax is obsolete. Nor is it discouraged, nor is "[]" a best practice, nor is really anything true besides there being two array syntaxes available. Frankly, I think [] gets lost in the mess of other symbols too easily. It's sure handy for writing an array but sometimes I like seeing the word "array" for clarity.

No it is not.

If you want to make sure $argument is an array then you need public function authorize($ability, array $arguments)If you want the default value to be an empty array then you need public function authorize($ability, $arguments = array())If you want both - which I suspect is the case - then do both.

The DOCUMENT_ROOT method is the best method. Remember that it starts at the root of your website (which is apparently "media"), not the current directory. Using __DIR__ is the second best method and is relative to the current directory. include(__DIR__ . "/inc/chaserData.php");

I have no idea what your code is so no, I don't really have any ideas for what to look for. Assuming you have a copy installed locally, try running with a debugger.

Don't store comments in a text file. Get a database. Even a SQLite database will do the job, if you don't have a real one available. Then all you have to do is run a query on the database to see if the BTC address (being the most reliable piece of information you have) has already been entered.

So how much PHP do you know?

That code will return an object (or null). There's something else going on.

As the error message says, $render $render = $this->getRender("object");is a string. Not an object. Are you misunderstanding how getRender() works?

Do you have access to the SMTP server logs? Or your hosting provider? Can you confirm that the server is receiving an email message as expected? Alternatively you could (maybe) set up a local sendmail that logs everything, then send your email through that and compare the messages when sent through cron and the browser. In other words, gather information. Confirm that stuff is working at it should at each step after your code. Compare what you see with and without cron.