Variable plötzlich nicht mehr vorhanden

functionen haben einen eigenen Namensraum, das heisst es sind nur die Variablen bekannt, welche auch in der Funktion deklariert wurden.
Verfügbar sind natürlich die Globals($_GET, $_POST etc.). Du müsstest also die $resource variable als global deklarieren:

function tuWas() {
global $resource, $var2, $var3;
//mach was tolles
}

DAvon würde ich dir allerdings schwer abraten. Die Gründe kannst du dir ergooglen, sind ne Menge
Besser wäre es, du übergibst die $resourtce an die Funktion als Argument.

Arbeitest du mit mehreren verschiedenen DB-Verbindungen parallel? Sonst kannst du $resource auch einfach weglassen.

Edit: Da du dort mit $_COOKIE arbeitest und diese Werte vom Client kommen solltest du dringend mysql_real_escape_string verwenden.
Und was mir noch auffällt, du führst den Query der in $last_hit_sql steht nie aus.

Edit2: Achja, und Datum/Zeit sollte nich als Unix-Timestamp in der DB gespeichert werden. SQL stellt genügend passende Feldtypen dafür zu Verfügung, die eine Menge Vorteile bieten und keine Nachteile (von denen ich wüßte).

Zitat von Santos

Für was genau ist dieses mysql_real_escape_string?

Wie bandit schon sagt -> Doku

Aber um mal ein kleines Beispiel zu bringen:
Nimm mal an ein, ein Besucher manipuliert seinen Cookie, so dass sein Benutzername auf auf einmal so aussieht: '; DROP DATABASE;
Wenn du das in deinen Query einsetzt sieht der so aus: SELECT passwort_hash,last_hit FROM ht_user WHERE username = ''; DROP DATABASE;
Könnte unerwünschte Auswirkungen haben.
mysql_real_escape_string sorgt dafür, dass entsprechende Zeichen ausreichend maskiert werden um sie gefahrlos in SQL-Statements benutzen zu können.
D.h. JEDER Wert der vom Client kommt (also alles aus POST, GET, COOKIE) soll IMMER mit mysql_real_escape_string entschärft werden, bevor der Wert in einem SQL-Statement verwendet wird.

Noch besser ist allerdings direkt mysqli oder pdo mit prepared Statements zu verwenden. Da wird das automatisch gemacht und du brauchst dich nicht mehr selber drum kümmern.

Zitat von Santos

Ich sehe darin keinen Vorteil für mich das Datum und die Zeit nicht als Unix-Timestamp zu speichern. Aber danke für deine Vorschläge

Der einzige Fall in dem es keinen Unterschied macht ist der, wenn du in deinen PHP-Skripten auch ausschließlich den Unix-Timestamp verwendest und nicht mehr in andere Datumsformate umwandelst. Aber selbst dann könntest du, wenn du z.b. datetime als Feldtyp verwendest, in deinem SELECT-Statement einfach schreiben SELECT UNIX_TIMESTAMP(`mein_datetime_feld`) ... und bekommst das gleiche Ergebnis.
Die SQL-Eigenen Feldtypen für Datum und Zeit zu verwenden hat zwei große Vorteile:
1. Die Lesbarkeit in der Datenbank. Wenn du in phpmyadmin direkt mal was nachschauen willst, mußt du einen UNIX-Timestamp erstmal umständlich umrechnen um ein lesbares Datum zu erhalten (es sei denn du bist irgendein überkrasses Rechengenie und machst das auf einen Blick).
2. Du kannst mit den Datumswerten direkt in deinem SQL-Statement schon wunderbar rechnen, alles ins passende Format bringen etc. Und das ist einiges schneller als die Berechnungen und Umformungen von PHP vornehmen zu lassen.
Ein Beispiel mal aus einem aktuellen Projekt von mir, bei dem ich gerne mal sehen würde wie das jemand in einer Abfrage ohne weiteren Programmcode umsetzt, wenn er seine Daten als Unix-Timestamp speichert:

SELECT 
				id,resource_id,title,value,isRegular,timeMin,timeMax 
			FROM 
				schedule__resource_content
			WHERE 
				job_id=? 
				AND
				(
					postDate=? 
					OR
					(
						endDate>=?
						AND
						(
							isRegular=1
							OR
							(DATE_FORMAT(postDate,'%w')=DATE_FORMAT(?,'%w') AND isRegular=2)
							OR
							(DATE_FORMAT(postDate,'%d')=DATE_FORMAT(?,'%d') AND isRegular=3)
						)
						AND
						id NOT IN (SELECT pk_content_id FROM schedule__resource_exception WHERE pk_exceptDate=?)
					)
				)
			ORDER BY
				resource_id,postDate,timeMin,title ASC

Es geht um die Ermittlung von Terminen an einem bestimmten Tag.
Diese stehen in der Tabelle `schedule__resource_content`.
Es gibt einmalige Termine (isRegular=0), tägliche Termine (isRegular=1), wöchentliche Termine (isRegular=2) und monatliche Termine (isRegular=3).
Mit dieser einen Abfrage hole ich mir für einen bestimmten Tag alle Termine ohne weitere Abfragen zu starten oder in PHP noch selektieren zu müssen.
Wie gesagt, das würde ich gerne mal sehen bei Speicherung des Datums als Unix-Timestamp (ich schließe nicht aus, dass es möglich ist, allerdings wüßte ich grad nicht wie und es wäre vermutlich etwas komplizierter und schlechter lesbar).

Wenn du nur Hobby-mäßig kleinere Webseiten ohne komplexere Funktionalitäten entwickelst, und auch keine weitergehenden Ambitionen hast was das Programmieren angeht, dann verwende ruhig weiter den Unix-Timestamp, die Performance-Unterschiede werden sich bei simplen Seiten mit durchschnittlichen Besucherzahlen nicht bemerkbar machen.
Falls du aber auf lange Sicht vorhast professioneller zu programmieren kann ich dir wirklich aus eigener Erfahrung raten so früh wie möglich solche Konventionen zu nutzen, denn sie machen durchaus Sinn. Und je mehr du dich an einen anderen Weg gewöhnst, desto schwerer wird es später sich das wieder abzugewöhnen.

Ich weiß, das ist ein Thema auf dem ich gerne rumreite, aber es wird halt so oft "falsch" gemacht. Und mir konnte bisher noch niemand einen klaren Vorteil bei der Verwendung des Unix-Timestamps gegenüber den Datums-Feldtypen von SQL nennen.

Jap, genau so.
Und das mit allen in SQL-Statements verwendeten Daten die vom Client kommen.

Naja, wenn der Geldbetrag das einzige Kriterium ist, nach dem der Rang bestimmt wird, dann ist das so ja schon richtig. Dann haben Personen mit dem gleichen Geldbetrag auch den gleichen Rang. Wenn du ein weiteres Kriterium für den Rang hinzufügst kannst du das natürlich ändern, aber ein weiteres Kriterium brauchst du.
Eine Möglichkeit wäre zum Beispiel der Zeitpunkt seit wann derjenige diesen Geldbetrag hat als weiteres Sortier-Kriterium. Wenn also zwei Spieler 150,- EUR haben hat der Spieler den besseren Rang, der schon länger 150,- EUR besitzt.
Dafür müsstest du deine Tabelle `ht_user` um eine Spalte erweitern in der du bei jeder Änderung des Geldbetrags die aktuelle Zeit speicherst (z.B. `geld_lastModified`).
Die Abfrage könnte dann so aussehen:

SELECT 
  COUNT(*) AS anzahl 
FROM 
  ht_user 
WHERE 
  (
    geld>'{$user['geld']}' 
    OR 
    (
      geld='{$user['geld']}' 
      AND 
      geld_lastModified<'{$user['geld_lastModified']}'
    )
  ) 
  AND 
  gesperrt=0

Klar, das kannst du auch machen, dann nimmst du in meiner Beispiel-Abfrage einfach 'registriert' stattn 'geld_lastModified' und änderst das <-Zeichen in einer >-Zeichen.