requinix

Compare the output of phpinfo() on the two hosts. Normally these white page issues are because of syntax errors, and if it's happening after a migration then it's quite likely that the PHP versions and/or configurations don't match.

They don't disallow it - they can't, there's no way to. But they can tell you that using the normal session is pointless, and it is for the reasons they stated. Except you can use sessions in a database instead. Since all the cloud servers can access the database they can also share the session information. Normal sessions are handled with files and PHP just reads and writes variables and values in them. So instead of files you configure PHP (by writing code) to use a database instead. The rest of the session stuff with $_SESSION and session_start() still applies without any changes, but behind the scenes PHP goes through some custom code for loading and saving.

Don't let them post HTML and instead allow BBCode (or something similar). People can still enter links and images, format with bold and underlines, change font size and color... It's a different yet very similar syntax, but it's so common nowadays that the people who do know HTML 99% likely know BBCode as well.

Considering the flak we gave you for the other one, I'll try to be nicer. It's possible if you use file locking but know that there are situations where it will not work. Basically you open the file, lock it so that other processes can't read from it, do your work, then unlock and close. File locking flock file_put_contents can lock starting with PHP 5.1 However this is another one of those things that you really should fix, especially given that you'd have to implement the locking logic everywhere you read from or write to a file anyways. Even giving you some credit for dealing with the other problem isn't enough to deal with this particular issue. It will cause problems. Databases are much easier to deal with and are definitely worth the additional time to learn and use and you don't have to worry about any of this locking nonsense.

Bad news. You should be storing all this stuff in a database, not flat files (as it's called).

So I could post, say, <br /> malicious_code(document.cookie, document.location);<br /> where malicious.js is, well, malicious. You wouldn't mind that?

All those hash=, responseText=, and so on are the keys. There's no intermediary array or something. Assuming they POST it, $_POST["hash"] $_POST["responseText"] // etc The $fields stuff should always be there but $Address ones might not be. There's also the END that I'm sure you'll want to ignore. If you still can't get to it, dump out $_POST (or $_GET) with var_dump() or print_r() and see exactly what you're getting. (that's assuming the rest of their stuff works... those rtrim()s they have cast some doubt)

Throw in a DISTINCT. SELECT COUNT(DISTINCT the column about the trophy) as num1... Side note: when doing stuff with strings in PHP, always use quotes. Field names from SQL queries count. $total_trophies["num1"]

Then... you need to change the query? With a name like "id" I would have expected it to be unique for the entire table, but I guess that's not the case. Does it have the same value for the same kind of trophy? So all Trophy 1s have one value while all Trophy 2s have a different one value?

Yep.

It "inherits". The reality is that PHP keeps executing from where it left off - nothing changes, nothing resets, nothing goes away. It's basically the same as copy/pasting the code from script_2 into script_1.

Do you want to allow people to enter HTML?

I didn't say you can hide the source code. That's not possible. But you can hide the actual location of the image. I'm not going to tell you how because: What you have now is bad. It needs to change because it is bad. Doing anything other than fixing it is also bad. The fact that it may take a lot of work doesn't matter - it needs to change.

Like I said in the other thread :-\ it's possible to hide the location of the image but you still need to redo the system.

Yes, but you still need to redo it.

And that there is the downside to getting these kinds of script on the Internet: iffy support. You should get a programmer to go through everything. That's a fact but perhaps not a necessity. Do you know anything about PHP or MySQL? Is there a phpMyAdmin you can use to access the database (or something similar)?

First, understand that mysqli doesn't really do a whole lot of work. Everything comes from the MySQL C library. So most of the answers to your questions are along the lines of "the code calls the appropriate function from MySQL's C library". Besides that, 1. The query is prepared (which involves it being parsed for validity), you bind a value to the one parameter, the query and bound values are sent to the MySQL server, the server does whatever it does, and handle to the result gets passed back to the library. Your code then instructs that the resultset gets stored in memory, you bind variables to columns, each row is (re)read, and the variables are updated. mysqli itself only does a bit of that. 2. In memory. 3. It binds stuff internally in pretty much the same way the PHP code binds stuff. It does not set values (which it does via references) until you begin (re)reading the resultset. 4. The code calls the appropriate function from MySQL's C library and does some other stuff.

By reading the rest of what kicken wrote. After you've done that, go talk to Google instead of us.

Do you have a proxy for your Internet connection? Ever had 504 problems with other sites? On that error page, what is everything it says? There's normally a server name and information at the bottom.

- Keep that tag and/or a header("Content-Type: text/html; charset=utf-8"); - Save without the BOM. Otherwise PHP will incorrectly output that BOM right when it parses the file and you won't be able to use functions like session_start() or header(). Another thing: if you're writing these values inside the PHP file itself (like the code you posted) then the file itself has to be UTF-8 too.

One of them is $a and one of them is $b.

It's actually showing them in whatever order the operating system and file system says. That tends to be oldest to newest but isn't guaranteed. glob() will get you an array of files. You need to sort this array based on whatever criteria you want, and usort is appropriate for that. $files = glob("images/*.*"); function sortnewestfilesfirst($a, $b) { return filemtime(???) - filemtime(???); } usort($files, "sortnewestfilesfirst"); If I tell you that: - usort() takes an array and a function to use to sort the array - the function takes two arguments and must return: a number 0 for the reverse, and =0 if they're the same - filemtime() returns the last modified time of a file as a Unix timestamp (ie, a number) with smaller numbers being older can you replace the ???s with the appropriate variables?

Because PHP doesn't let you do that. And it kinda violates object-oriented design. Poodle has chosen to hide Dog's bark() method with its own implementation for whatever reason (that you may or may not know about). You are not allowed to "go around" that and call Dog::bark() instead.

$furball->Dog::bark(); That's a syntax error. You cannot use $furball to call Dog's bark() method. You can, however, put something in Poodle that will. But what (I think) you're trying to do should look more like class Dog { public $name; public function bark() { echo "{$this->name} says {$this->getBarkNoise()}!"; } protected function getBarkNoise() { return "Woof"; } } class Poodle extends Dog { protected function getBarkNoise() { return "Yip"; } } $furball = new Poodle(); $furball->name = "furball"; $furball->bark();

Contact your hosting provider. They're the ones that need to look into this.