requinix

Always use absolute paths. $Proverb = file($_SERVER['DOCUMENT_ROOT'] . '/proverbs.txt'); // might need /PHP_Projects/ChineseZodiacs in there too?

Not necessarily. I got along fine for years without having to learn that stuff. However it is good to know how PHP behaves on different OSes, especially Windows vs Linux/Mac. Composer doesn't have any crazy installation or anything - it's really just a few more files that you use along with your code. The main composer file is a PHP script (kinda) that you run normally (kinda), and there's generally a .lock file you keep around which is really just JSON. Uninstalling is a matter of deleting a couple files; you could use Composer to "install" the files you need, then remove it. I really, really don't like installing stuff on my computer if I can avoid it, but I don't mind Composer. If that tells you anything. That is getting a bit more complicated, and really more than you need to worry about just to deal with Laravel. I can't say anything about VirtualBox on a Mac but it shouldn't be that difficult. It kinda depends on your hardware but the only difference should be how well VirtualBox performs. You'd want to run a Linux operating system: Windows requires licensing, Mac... I think you'd have similar issues. Plus Linux will just be easier performance-wise to run. If you're having specific problems then you can ask, of course - you don't have to figure it all out yourself.

Please help because... the image isn't working? You have your quoting mixed up: echo '';

Yeah, that's fine. Off-topic: don't name that one method "use". You must be using PHP 5.2 because in 5.3+ that's a keyword and you can't use it as a method name. On that note, you should upgrade! PHP is at 5.6 now and there's been a lot of time elapsed, not to mention changes made, since 5.2.

The "similar methods" thing is inheritance and polymorphism at work: code doesn't necessarily need to know the exact type of item, just that it's an item and can be use()d. Factories can be used a lot, even to the point of factories of factories, and for the most part all you're doing is adding a bit of (worthwhile) overhead. If you find yourself needing if or switch blocks to construct the different types of classes, a factory is probably a good idea. - Items probably could use a factory. Somehow you can identify an item, right? Like the string "food" or "weapon" or "toy". Perhaps with some other information useful to the item itself. A factory can be used there: if you can standardize on a constructor, like public function __construct(array $config) {then you can use a factory. public static function factory($item, array $config) { // if your item classes are all named uniformly, like "FoodItem", and you have an item identifier "food" $class = ucfirst($item) . "Item"; if (class_exists($class)) { return new $class($config); } else { trigger_error("No such item '{$item}'", E_USER_WARNING); return null; } }- Tutorials don't actually sound like they need a factory. I'd imagine that a tutorial is "started" in very specific places in code, and so adding more tutorials is not just a matter of writing a new class. - Random events probably have a bit of information attached to each, like the weight/probability of the event, but it's quite possible that you can use a factory here like you can for items.

So it's not that then. You have code that checks the subdomain, presumably using HTTP_HOST. Modify the code so that it does more than just check the subdomain, such as "if the host is X.mydomain.com then the user is X, else if the host is not *.mydomain.com then determine the user by looking up the entire hostname in the database". If you want more help then you'll have to explain the system in much more detail. Like where the subdomain checking takes place, how you're looking up the user, and where you're storing the custom domain names. And the code to go along with it. Oh, and this entire system will only work if you have dedicated hosting.

$filename is an example. You have to change it according to your code.

Unless you're running on a system with memory measured in the hundreds of megabytes, it does not "waste so many resources". But hey, nothing says you have to use so many classes. Do whatever gets you the quick win now.

Polymorphism would be a good first step. interface IProductPdfWriter { public function add($pdf, $vars); } abstract class BasicProductPdfWriter implements IProductPdfWriter { public function add($pdf, $vars) { // ... } } class ProductBPdfWriter extends BasicProductPdfWriter { } class ProductCPdfWriter extends BasicProductPdfWriter { } class ProductDPdfWriter extends BasicProductPdfWriter { } class ProductAPdfWriter implements IProductPdfWriter { public function add($pdf, $vars) { // ... } }Class loading could be done a number of ways, like constructing class names $class = "Product" . ucwords($product) . "PdfWriter"; $writer = new $class();or using a mapping somewhere $classes = array( "A" => "ProductAPdfWriter", "B" => "ProductBPdfWriter", "C" => "ProductCPdfWriter", "D" => "ProductDPdfWriter" ); $class = $classes[$product]; $writer = new $class();(you wouldn't need the dedicated B/C/D classes and could just use BasicProductPdfWriter for the three)

Windows and PHP have never gotten along when it comes to non-ASCII filenames. PHP is not a Unicode program (as far as Windows knows) so it gets special treatment when it comes to filenames, but that special treatment can be a big problem. The best solution I know is this class. It requires the com_dotnet extension so if you cannot load that then you're out of luck. You use it like this: // say you want to write to a file named "C:\العربية.ext" $filename = "C:\\العربية.ext"; // first you need to make sure the filename is UTF-8 encoded. in your case it probably is // if not then you can use $filename = mb_convert_encoding($filename, "UTF-8", "original character encoding"); // now you detect windows systems. this is good for portability if (strncasecmp(PHP_OS, "WIN", 3) == 0) { // WindowsStreamWrapper requires the com_dotnet extension if (extension_loaded("com_dotnet") || function_exists("dl") && dl("com_dotnet")) { // if you do not have autoloading, //require_once("path/to/Patchwork/Utf8/WindowsStreamWrapper.php"); // while you can use the class normally, it is easier to use it as a stream wrapper // you can use any label for the stream wrapper name. I chose "winfs" stream_wrapper_register("winfs", "Patchwork\\Utf8\\WindowsStreamWrapper"); $filename = "winfs://" . $filename; } // if we cannot load the extension, ASCII filenames are safe and we don't have to worry about them // this detects bad filenames by looking for high bytes: 127-255 else if (preg_match('/[\x7F-\xFF]/', $filename)) { // there is no good solution. you may decide to raise a fatal (!) error //trigger_error("The com_dotnet extension is required for non-ASCII filenames but cannot be loaded", E_USER_ERROR); //exit; // or you can substitute a different filename and let the code continue // this is better in practice because a file with the wrong name is better than no file at all $filename = dirname($filename) . "\\" . uniqid(time(), true) . "." . pathinfo($filename, PATHINFO_EXTENSION); // (be careful: the file extension may not be ASCII either! in this code I assume it is) } } // now you can write to the file the same way you normally would. for example, file uploads still use move_uploaded_file(): move_uploaded_file($_FILES["foo"]["tmp_name"], $filename);

How are you doing the dynamic subdomains? Virtualhosts or a wildcard?

And part of your job is to teach them why it's bad.

Have you tried using mysqli_error to get an error message?

If the client is at all technical, like they want to query the database directly, then you can make a view of whatever the appropriate query is. It will look like a regular table for the most part.

Don't do that - have multiple tables for the same thing. The big clue that it's a bad idea is that you have to run some automated thing to manage your database. Any particular reason you want them in another table? Is there a problem with just querying the table directly?

The only time when you'll get that 0.005 row is if $prob == 0 and that will never happen because the range on the random number is [0.05, 1].

You think there's something wrong?

There may be other problems that aren't obvious... You need to make a change to your php.ini file: run phpinfo() in a script and it will tell you where you can find the file near the top. Hopefully you do have one. In there are two settings to change: error_reporting = -1 display_errors = onThey exist in the file somewhere and probably in two locations: one place describes a bunch of settings, the other is the actual location where the setting is defined. Possibly commented out with a semicolon, in which case you need to uncomment it after changing the value. When you do that, restart Apache and run phpinfo() again. Then look for those two settings - they should have the new values. Then try your script again. There will probably be some kind of error message. Or more than one.

Use the normal, long open tags. Short ones only work if you happen to have PHP set up to accept them. (= is an exception which will always work - with recent versions of PHP.)

Almost. http://home.online.no/~pjacklam/notes/invnorm/impl/nickerson/inverse_ncdf.php See also http://home.online.no/~pjacklam/notes/invnorm/ That returns normal values, ie. 0=mean and +/- 1 is one standard deviation, however you can transform that easily with inverse_ncdf($p) * $stddev + $mean

You can't submit a form to two locations. I don't know what this testpage is for but can't you redirect to it after the PayPal process completes? If not, what is it for?

Well, see, I know you didn't copy/paste that from the access log because it's incorrect. So I said something's not adding up? Here it is: In the first post you said you went to /index.php but in the second post you're showing (if I read between the lines) access logs that correspond to a request for /xxx/index.php. You've posted your two domain names previously so there isn't really a reason you need to try to hide them anymore. As such, can you please post the exact access log lines that show the URLs you are visiting that return 404s?

Only recent versions of PHP (5.5+ I think) allow you to pass a non-variable to end(). If you're running an earlier version then you need a temporary variable. But there's a better way to get file extensions: $end = pathinfo($thum, PATHINFO_EXTENSION);

Yes. Outdated enough that it's no longer being supported. Even 5.4 is only getting security fixes now. Start upgrading. Go through the 5.4 and 5.5 changelogs, evaluate the impact on your application, make changes, test, all that stuff.

There is no PHP setting that will drop @crypt when parsing. You're barking up the wrong tree. What happens if you parse_str() on the raw QUERY_STRING?