Beiträge von Arne Drews

So auf die Schnelle habe ich jetzt keine Beispiele für Sockets in Bezug auf Chats.

Das Prinzip ist aber eine Server-/Client Abhängigkeit. Man benötigt dazu nicht zwingend einen speziellen Hoster, es muss halt nur möglich sein, auf dem Server einen Socket-Server zu initiieren.

Diese Socket-Server lauschen i.d.R. auf bestimmten Ports und verarbeiten die Anfragen, die dort reinkommen und senden die Antworten zurück.

Ganz grob nicht viel anders, wie Polling, nur das beim Polling ein bestimmtes Script angestoßen wird und so lange läuft, bis sich bspw. eine Änderung ergibt und beim Socket ein Dienst bzw. Daemon permanent läuft.

Vielleicht solltet Du Dir Polling bzw. Sockets ansehen.

Eine 3 sekündliche Aktualisierung vom Client gesteuert halte ich für etwas dirty...

Eine reine PHP-Lösung gibt es nicht, da immer eine Aktion vom Client aus gefeuert werden muss.

Ich würde noch einen Schritt weiter gehen und nur die CSS-Klasse auf dem Modulo basieren lassen, anstatt die gesamte Zeilenausgabe.

Die Ausgabe wird vom Typ immer gleich sein, bspw.:

<div class="chatmsgrow">
    <div class="author"><span>Hans Wurst</span><span>27.07.2018 07:05:23</span></div>
    <div class="message">foobar is baz</div>
</div>

Je nach Modulo gibst Du dann dem Container die zusätzliche Klasse left oder right, bspw.:

<div class="chatmsgrow left">
    ...
</div>

<div class="chatmsgrow right">
    ...
</div>

Wenn Du die chatmsgrow nach dem Flexmodell aufbaust, kannst Du per CSS die Anordnung der Childs für right einfach umdrehen:

flex-direction:row-reverse;

Dein PHP sähe dann in etwa so aus:

$aChatMessages = [];
$sChatMessageTemplate =<<<EOHTML
<div class="chatmsgrow _ANCHOR_">
    <div class="author"><span>Hans Wurst</span><span>27.07.2018 07:05:23</span></div>
    <div class="message">foobar is baz</div>
</div>
EOHTML;


if ( $result ) {

    $iCount = 0;

    while ( $row = mysqli_fetch_assoc($result) )
        $aChatMessages[] = str_replace( '_ANCHOR_', (($iCount++%2) ? 'left':'right'), $sChatMessageTemplate );

}

Nur als Beispiel, die Namen und Datum/Uhrzeit, sowie die Nachricht selber musst Du natürlich mit ersetzen.

Im HTML kannst Du die Messages dann komplett ausgeben: echo implode( $aChatMessages );

Auch bei einem leeren <iframe> hat das einen Hintergrund, warum das nicht geht. Das liegt an der Beschaffenheit bzw. am Grundgedanken des Element.

Alles, was sich im <iframe> anklicken lässt wird innerhalb des <iframes> getriggert. Eine Klick sensitive Hintergrundgrafik gehört zu dem DOM, das sich innerhalb des <iframe> befindet und kann ohne weiteres nicht in den Parent projeziert werden.

So ähnlich würde ich das auch sehen. Allerdings glaube ich, dass das Modal nur eine Sicherheitsabfrage á la "Sind Sie sich sicher?" sein soll. Dann benötigt man für den Content des Modal nicht mal AJAX. Der Löschprozess könnte dann auch ohne AJAX durchgeführt werden.

Zitat von Stef

Hey,

Arne Drews : Dies ist kein Quatsch. Weist du denn wie das ganze System eigentlich aufgebaut ist? Ich meine nicht.

Sorry, so wie er das geschrieben hat, ist das nun mal doch Quatsch!

Ob ihr über GET-Parameter geschrieben habt oder nicht, entzieht sich meiner Kenntnis. Ich kann nur das beantworten, was ich lese.

Zitat von Stef

Es gibt eine Session mit der User Id welche die Id des eingelogten Users besitzt.

Jo: $_SESSION['userid'] oder wie der Key halt heißt.

Zitat von Stef

Dann gibt es noch die ganzen User IDS welchen den Buttons zugeordnet werden.

Die sich idealer Weise in einem <form> befinden? Bei reinen <a> Tags ist es natürlich dann GET, sonst idealerweise POST.

Man könnte das auch <form>los über pure <button> realisieren.

Zitat von Stef

Und wenn man auf ein Button klickt wird in die URL der Parameter Id = 0 angehongen. Somit hat man eine Value auf die man mittels GET zugreifen kann. Und diese Value besitzt die Id des angeklickten Userbuttons.

Und da steckt der Gedankenfehler: Er hat einen Modal-Fetisch. Bei Modals hast Du zunächst mal keinen direkten Request, zumindest wenn man das Prinzip sinnvoll einsetzt. Ergo: kein GET-Parameter!

Sein data-target macht prinzipiell schon Sinn, er verwendet das nur nicht korrekt.

In einem <iframe> werden üblicherweise externe HTML-Inhalte dargestellt, die selbst Klick sensitive Elemente haben können.

Wie soll das funktionieren, wenn Du den <iframe> klickbar machen willst?

Wenn Du für Dich allerdings festlegst, dass im Dokument des <iframe> nicht geklickt werden darf/braucht, kannst Du natürlich einen Layer in Form von bspw. einem <div> darüber legen und dessen Klick-Ereignis anzapfen.

Na die ID hast Du doch im Value des Button-Links

Das ist quatsch. Wenn es in der Session steht, kommst Du mit $_SESSION['userid'] ran, je nachdem, ob der Key wirklich userid ist.

Dann hat er aber sicher auch gemeint: per GET senden und empfangen...

Wobei POST für Formulardaten weiterhin die sinnvollere Variante ist.

Zwecks Anordnung würde ich Dir auf jeden Fall das Flexmodell (CSS) empfehlen.

Die Darstellung ist relativ einfach über <div> mit overflow realisierbar oder alternativ auch <iframe>, wenn es sein muss.

Die Seiten holst Du Dir dann per Ajax über JavaScript.

Jo, ich frage mich nur, wer den Tipp gibt, das dann mit $_GET auszulesen...

Für einen eigenen Server bedarf es Fachkenntnisse in den Bereichen Server-Administration/-Konfiguration und Sicherheit.

Und gerade bei im Netz öffentlich erreichbaren reichen Grundkenntnisse da nicht aus.

Lass das bitte sein oder nimm zumindest einen Managed, falls Du Dich doch dafür entscheidest.

Kommt ja drauf an, wie Du das Formular sendest. Wenn das mit POST sendet, kann in $_GET nichts drin sein...

Ja, aber Du willst doch den Leuten hier, wie bspw. basti1012 - nicht persönlich nehmen - nicht ernsthaft einen eigenen Server ans Herz legen?!

Dann bist Du doch einer der ersten ( wie ich auch! ), die bei Fragen zu Problemen ähnlich antworten wie: Lass das lieber die Profis machen!

Das passt so auch nicht zusammen, sorry...

Zitat von ezcotrix

Ach ich bin doof. Hab grad die contact.php gefunden. Trotzdem danke

...und lass mich raten: darin gibt es eine mail() Funktion?!

Dem <form>-Tag nach zu urteilen, wird es sich um das Affenformular-Prinzip handeln.

Dann könnte der entsprechende PHP-Code sich im Script oberhalb des HTML befinden. Sollte das Script auf Templating basieren, kann es sich natürlich auch woanders befinden. Ohne das Script zu kennen, kann man wohl nicht viel mehr sagen...

Und wo steht die Frage???

Wenn Du etwas gekauft hast, hast Du normalerweise auch etwas Support, hast Du den mal in Anspruch genommen?

Nicht immer so pessimistisch, auch die haben einen Support. Reaktionszeit ist sicher nicht die beste, aber da gibt es noch deutlich schlechtere...

Ich weiß ehrlich gesagt nicht, was Du da tust, weißt Du's?

Ich erkenne bspw. keinen Grund, das Modal über eine Schleife aufzubauen, wo btw. Dein Problem liegt, denn der letzte Eintrag ist in dem Beispiel Louis, was Du jedesmal erhältst. Der Lösch-Button sollte bereits eine Assoziation zu dem entsprechenden User haben.

Dann mal ne Frage am Rande: Hast Du'n Modal-Fetisch? Mir scheint, alles, was Du umsetzen möchtest, muss über Modals laufen?!