requinix

- I could write out an explanation of namespaces, but it would be easier to just point you to the documentation. Namespaces are optional but more "professional" than continuing to name classes with underscores. - spl_autoload_register is about autoloading. It means you don't have to do a require_once for every single class file you need. If you're familiar with __autoload, spl_autoload_register is a better alternative. - PSR-4 is a recommendation about how to use namespaces. It's pretty basic, one of the least controversial PSRs, and almost universally accepted. <?php // root/code/MyWebsite/Core/User.php namespace MyWebsite\Core; use MyWebsite\Model; class User { public static function get($username) { $user = Model\User::get($username); // MyWebsite\Model\User return $user ? new self($user) : null; } } ?> <?php // root/code/MyWebsite/Model/User.php namespace MyWebsite\Model; use MyWebsite\Db; use MyWebsite\ModelBase; class User extends ModelBase { public static function get($username) { $db = new Db(); // MyWebsite\Db $row = $db->get("users", "username", $username); return $row ? new self($row) : null; } } ?> <?php // root/bootstrap.php // this autoloader only applies to MyWebsite\* classes spl_autoload_register(function($class) { if (strncmp($class, "MyWebsite\\", 10) == 0) { $file = __DIR__ . strtr($class, "\\", DIRECTORY_SEPARATOR) . ".php"; is_file($file) && require_once($file); } }); ?> <?php // root/public/login.do.php require_once("/path/to/root/bootstrap.php"); $user = MyWebsite\Core\User::get($_POST["username"]); if ($user->login($_POST["password"])) { header("Location: /"); } else { header("Location: /login?invalid"); } ?>Can you ask more specific questions than just "please explain everything"?

If Concrete\Core\Block\BlockController is located in /var/www/concrete5.7.5.9/concrete/src/Block/BlockController.php then it's a good bet that any Concrete\Core\* class is located in /var/www/concrete5.7.5.9/concrete/src/*.

No, don't change the include path. Just replace that one require_once you had with the one I posted. So <?php //require_once(dirname(__FILE__) . 'ru_4pear.php'); ini_set("include_path", ini_get("include_path") . ":/home1/nuclearp/public_html/libs/pear/"); require_once('/home1/nuclearp/public_html/libs/pear/DB.php');The point is to see whether the file can be included successfully at all.

Does require_once('/home1/nuclearp/public_html/libs/pear/DB.php');work?

Unless there's something out there that has pre-written code for doing tests like the ones you need (I'd be somewhat surprised), you're going to end up writing those tests by yourself anyways. That TestAPI thing seems decent. You also don't have to necessarily write a test for every single aspect. Testing only for valid situations is a legitimate testing strategy. My advice is to test just for the valid situations now and move on to other more important problems. If you find a bug with your current implementation, write a test, fix it, (rerun all the other tests to be sure nothing broke,) then go back to what you were doing before.

You validate by writing and running tests. Like you're doing. Testing as a whole is a complicated subject, but the short version is to have an automated way of checking that successful scenarios are successful while failure scenarios are failures. "Automated" so it encourages you to run them as often as possible; a way to get terse output (eg, only show failures) would be nice so you don't have to parse a lot of output to get your answers. How you go about writing tests varies: there are testing frameworks out there to help, but making your own (provided you don't spend too much time on it) is fine too.

Looks like the problem is with installing KB2999226. Can you get a copy of it from here and try installing it manually? At the very least it should give some sort of message if it fails, and hopefully one more useful than 0x80240017.

Looks like you had WinSCP set up with a host using a keyfile. Did you copy the keyfile too?

I don't know which download you used but apparently people with that error have been able to get this one to work.

Not really? It's only visible to people who copy and paste stuff (which search engines won't do) and when they do paste the link is right there and hard to miss.

If you are trying to interpret what he said literally then yes, you're right, PHP does not "magically" generate HTML. However I think it's clear that what he meant was that PHP code must be used to create HTML - or any output, for that matter - and that it is not PHP by itself that is responsible for generating anything.

The HTML is Hello WorldIt's not exactly valid HTML, but that's what the browser will interpret it as by automatically wrapping it in an and .

Don't do anything simply based on the user returning from PayPal. It's just a URL. Anybody can visit a URL. You have to verify the transaction was successful. Personally I prefer to use IPN: PayPal submits a request to your server directly, including information, you verify the information (sending a request back to them in the process), and if everything is good then you consider the payment as being completed.

And your question is... how they do it? They do it by using a script from some folks named Tynt (which is apparently now called "33across"?). That script does it by... well, I'm not sure, it's obfuscated, but likely by a trick where you listen for an oncopy event, create a new hidden element with the selection plus the "read more" text, select that, let oncopy do its thing, then remove the element.

I can't imagine that a browser extension framework would provide access to the sorts of things you need. They're just not meant to do that. So that means installing a program (as in a real software application) on the client that would allow your server to make remote connections and control the client. Which is a horrible idea. So... no. Not possible. As for shared memory, that's something completely different and not the least bit applicable to your situation.

No. Such a thing would be a huge security risk for an operating system to allow. In fact they tend to go to great lengths to make sure that's not possible.

It is.

Make sure the bundle has the certificates in the right order: nginx expects yours at the top and the rest of the chain after.

Well, based on the syntax highlighting in your post, it appears you're missing a quote somewhere to end a string.

Before you go making changes to it, how about looking in the server error log for more information about the error - like that message suggests?

Then try writing the equivalent code. It uses a foreach loop and... well, that's it really. A single foreach loop.

Try using array_column on $array["opportunity_items"].

This forum works a lot better if you can ask specific questions. You've described the three database tables you need. Have you made them yet? Next step would be making the first page that shows the list of categories. Do you know how to do that? Have you ever used PHP to interact with a database? Have you done any research to see what you need to know and learn for it?

Oh. Wait until bots become an issue, then use CAPTCHA. I say to wait because doing that is a bit of an annoyance to users, so if you can get away with not using it then great... but CAPTCHA (the real solutions, not the stuff you make up on your own) is very effective at stopping bots so it's the best solution when do you have the problem.

You can't stop "bad bots" from getting to your site. They won't respect robots.txt. They'll crawl anything they can find. IP bans, at best, will just slow them down. You said they are "inserting rows into db". What does that mean? That sounds like the problem that should be fixed.